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Real-Worid  Software  Engineering 

I  MTROOUCIION 

a.  PuipoM  and  Goals 

Based  on  our  experience  teaching  software  engineering,  we  at  East  Tennessee  State 
University  are  convinced  that  a  one-semester  software  engineering  course  cannot 
adequate  cover  all  aspects  of  the  software  development  process  and  etui  provide 
students  with  meaningful  project  experience.  Current  software  engineering  oourse 
models  emphasize  either  the  product  or  the  process  [Shaw  91].  These  models  rarely 
finish  a  realistic  product  or  do  so  by  marginal  treatment  of  significant  aspects  of  the  life 
cycle.  For  example,  while  concentrating  on  implementation  details,  topics  such  as 
d^iied  design  reviews,  configuration  management,  arxi  maintenance  are  minmized. 

To  address  this  problem.  East  Tennessee  State  University  is  expandir^  and  changing 
its  undergraduate  curriculum  in  software  engineering.  Integral  to  this  effort,  we  are 
incorporating  into  the  undergraduate  curriculum  iess^  learned  while  developing  and 
teaching  software  engineering  courses  at  the  graduate  level.  This  proposal  was  to 
develop  a  two-semester  undergraduate  course  which  presents  real-world  software 
engineering.  The  course  provides  a  thorough  coverage  of  the  software  development 
process  with  realistic  proj^  experience. 

The  course  is  designed  to  present  software  engineering  in  a  layered  approach  where 
"inter-related  topics  are  presented  repeatedly  in  increasing  depth”  [Ford  87]. 
Furthermore,  the  relationship  of  softerare  engineering  principle  to  software 
development  is  emphasized  by  the  careful  coordination  of  project  and  lecture  stages 
[Shaw  91].  For  example,  in  the  first  four  weeks  the  students  are  rapidly  introduoed  to 
the  fundamental  principles  of  software  engineering  concurrent  with  a  small  project. 
During  the  remainder  of  the  first  semester,  a  thor^h  examination  of  analysis  and 
design  and  their  controlling  disciplines  is  presented.  The  second  semester  addresses 
the  remaining  principles  of  a  comptete,  mature  software  development  process 
[Humphrey  88]. 

In  order  to  provide  an  instructional  mechanism  and  realistic  project  experience,  the 
course  uses  both  the  "small  group  prpjecT  model  and  the  Targe  project  team"  model 
[Shaw  91].  The  first  project  is  a  "toy  prpjecT  which  is  fully  specified  by  the  instructor. 
The  management  organization  for  this  project  is  a  chief  programmer  team  [Brooks  82]. 
During  this  four-week  project,  the  students  are  also  introduoed  to  Ada  using  a  "program 
reading  methodology"  [Deimel  90].  Ada  is  also  used  as  the  specification  language. 
As  the  toy  project  nears  completion,  a  targe  project  for  an  external  cRent  is  introduoed. 
A  matrix  management  organization  is  us^  for  this  project.  The  first  semester  takes 
this  project  through  Preliminary  Design  Review.  Successful  deliverables  from  this 
semester  will  be  used  in  the  second  semester.  Emphasis  is  piaced  on  validation 
techniques  for  requirements  and  design.  CASE  tools  are  us^  to  document  and 


validate  the  designs. 


The  second  semester  has  three  miyor  project  components.  First  is  the  completion  of 
a  large  project  involving  a  real  client.  This  project  begins  with  a  baselined  design 
document,  specified  in  Ada,  and  continues  through  acceptance  testing.  The  second 
major  component  is  multiple  small  maintenance  requests  applied  to  an  Ada  artifact. 
This  disciplined  approach  to  maintenance  gives  the  students  experience  needed  by 
industry,  which  is  rarely  achieved  in  traditional  software  engineering  courses.  Finally, 
during  a  four-week  assessment  period,  various  fornial  methods,  metrics,  and  tools  are 
applied  to  the  three  course  projects.  In  this  assessment,  both  the  processes  and  the 
prr^ucts  are  evaluated  to  capture  their  strengths  and  weaknesses. 

Innovations  include: 

*  Ada  -  first  introduced  through  program  reading,  then  as  specification  and 
design  notation,  later  as  an  implementation  language; 

*  Industrial  Setting  -  working  on  multiple  teams  and  team  organizations, 
working  on  different  sizes  and  types  of  projects,  assuming  different  roles, 
experience  with  a  variety  of  CASE  tools; 

*  Continuous  Assessment  -  integrated  into  all  project  activities  using 
formal  reviews  with  an  emphasis  on  validation  and  verification  throughout 
the  life  cycle; 

*  Closing  Assessment  Period  •  a  period  dedicated  to  appraising  the 
strengths  and  weaknesses  of  the  processes  and  products  discussed  and 
developed  during  the  course;  and 

*  Professionalism  -  integration  of  professional,  ethical,  and  legal  issues  in 
accordance  with  the  recommendations  of  the  lEEE/ACM  Computer 
Society  Task  Force. 


b.  Technical  detaila  relating  to  this  document 

All  of  the  materials  used  in  this  course  have  been  formatted  in  WordPerfect  6.0  for 
windows.  The  entire  document  can  be  printed  using  that  software.  We  have  provided 
it  in  this  format  to  enable  easy  modification  and  adaptation  by  anyone  using  these 
materials  for  teaching  software  engineering.  The  only  restriction  is  on  the  material  in 
section  d  below  which  is  from  a  copyrighted  paper.  This  entire  package  of  materials 
is  also  available  in  postscript  format.  Both  the  wordperfect  and  postscript  versions  of 
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this  material  are  available  from  the  Defense  Documentation  Center.. 


c.  Structure  of  the  document 

These  materials  are  designed  to  be  used  as  a  complete  two  semester  course  in 
software  engineering.  The  materials  contained  herein  can  be  used  either  in  whole  of 
in  part.  For  example,  most  of  the  projects  can  be  adapted  to  a  one  semester  course 
in  software  engineering,  or  a  course  which  uses  Oh-,  rather  than  Ada  as  the  language 
of  choice.  The  lectures  are  self  contained,  all  relevant  overheads  and  handouts  are 
associated  with  each  lecture.  The  document  is  divided  up  by  pedagogical  tasks 
associated  with  teaching  an  extended  software  engineering  course.  The  tasks  indude 
lectures,  development  and  management  of  software  development  projects,  assessing 
the  students  work  in  those  projects  and  their  understanding  of  the  course  materials, 
and  tutoring  them  in  the  additional  languages  required  to  do  their  projects.  Although 
the  work  is  divided  into  sections  dealing  with  each  of  these  tasks,  the  material  in  each 
of  these  sections  is  cross  referenced  to  relevant  material  in  other  sections.  We  have 
also  included  a  section  on  resources  avdiable  in  the  summer  of  1994. 


d.  Course  Overview 

in  the  development  of  this  course,  we  presented  our  research  in  several  forums, 
induding  the  ^venth  Conference  on  Software  Engineering  Education.  The  description 
of  the  course  presented  there  is  appended  below. 
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Donald  Gotterbarn  uid  Robert  Riser 

East  Tennessee  State  University 
Johnson  City,  Tennessee  3760441711 


Abstract  A  one-semester  course  cannot  adequately  cover  the  software 
development  process  and  still  provide  meaningful  project  experience.  We  have 
developed  and  implemented  a  tightly-  coupled  two-semester  undergraduate  course 
which  presents,  in  a  spiral  form,  theoiy  and  practice,  product  and  process. 
Coordinating  the  increase  in  depth  of  die  lectures  as  topics  are  revisited 
repeatedly,  with  increasingly  demanding  ]»x>jects,  constitutes  our  spiral  approach. 
Three  projects  differ  in  size,  complexity,  team  structure,  artifacts  provided  and 
delivered,  and  development  methodologies.  The  projects  are  carefully 
choreographed  to  provide  varied  team  experiences  and  allow  each  student  to 
function  in  a  variety  of  roles  and  responsibilities.  The  project  ftamework 
provides  a  series  of  passes  through  the  software  development  process,  each  pass 
adding  to  a  body  of  common  student  experiences  to  which  sid»equent  passes  can 
refer.  By  the  middle  of  the  first  semester  studems,  individually  and  in  teams, 
have  begun  accumulating  their  own  "war  stories”;  some  pontive,  some  negative. 
This  personalized  knowledge  provides  a  solid  base  for  more  advanced  concepts 
and  classroom  discussion. 


1  Introduction 

Based  on  our  experience  teaching  software  oigineering,  we  are  convinced  that  a  one- 
semester  software  oigineering  course  cannot  adequately  cover  all  aspects  of  die  software 
development  process  and  still  provide  students  with  meaningful  project  experience. 
Current  software  engineering  course  models  emphasize  either  the  product  ot  the  process 
[Shaw  91].  These  models  rarely  fmish  a  realise  product  or  do  so  by  marginal  treatment 
of  significant  aspects  of  the  life  cycle  and  fnemature  immersion  in  implementation  details. 
For  example,  while  concentrating  on  implementation  details,  topics  su(^  as  detailed  design 
reviews,  configuration  management,  and  maintenance  are  not  given  adequate  attention. 


'  This  project  was  partially  ftindcd  by  DARPA  research  grant  DAALt3-92-G> 
0411. 
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To  address  this  problem,  we  have  expanded  and  chang«?d  our  undergraduate  curriculum 
in  software  engineering.  Integral  to  this  effort  we  have  nicorporated  lessons  learned  while 
developing  and  teaching  software  engineering  courses  at  the  graduate  level.  Moreover, 
we  integrate  graduate  software  engineering  milestone  reviews  into  the  undergraduate 
software  engineering  classroom.  A  DARPA  grant  enabled  us  to  complete  development 
and  implementation  of  a  two-semester  undergraduate  course  which  presents,  in  a  spiral 
form,  Aeory  and  practice,  product  and  process,  throughout  the  tightly  coupled  two- 
semesters;  mimicking  a  real-world  software  engineering  process.  ^ 

Our  course  differs  from  other  multi-semester  courses  in  two  ways.  First,  rather  than 
separating  theory  and  practice  into  different  semesters  [Adams  93];  we  blend  them 
duxHighout  Second,  rather  than  mistakenly  presenting  the  software  developmmt  life  cycle 
as  two  discrete  pieces,  analysis  and  design  in  one  semester  and  cotte  and  test  in  die  otiher, 
we  more  accurately  model  the  iterative  nature  of  software  development  Our  iqiproach 
combines  a  thorough  coverage  of  the  software  development  process  with  realistic  project 
experience. 

This  paper  describes  our  course,  related  experiences,  and  lessons  learned  during  its 
development  and  initial  offerings. 


2  The  Approach 

The  two-course  sequence  is  designed  to  present  software  engineering  in  a  layered 
approach  where  "inter-related  topics  are  presented  repeatedly  in  increasing  depth"  [Ford 
87].  Furthermore,  the  relationship  of  software  engineering  principles  to  software 
development  is  emphasized  by  the  careful  coordination  of  project  and  lecture  stages  [Shaw 
91].  Ihe  combination  of  these  two  techniques,  coordinating  the  increase  in  depth  of  the 
lectures  with  more  demanding  project  experiences,  constitutes  our  spiral  approach. 

The  course  is  built  around  three  projects  which  differ  in  several  significant  ways:  size, 
complexity,  team  structure,  artifacts  provided  and  delivered,  and  development 
methodologies.  The  projects  are  carefolly  choreographed  to  provide  varied  team 
experiences  and  allow  each  student  to  function  in  a  variety  of  roles  and  responsibilities. 

In  the  first  five  weeks  the  students  are  rapidly  introduced  to  the  fundamental  principles 
of  software  engineering  and,  while  working  in  teams,  they  complete  a  modest 
development  project.  Despite  the  introduction  of  sound  software  engineering  principles, 
the  simplicity  of  the  project  allows  student  teams  to  concentrate  on  the  end  product  rather 
than  the  development  process  and  still  achieve  a  modicum  of  success. 

As  the  first  project  nears  completion,  a  second,  extended  project  with  a  real  customer  is 
introduced.  It  spans  both  semesters  and  requires  revisiting  concepts  in  depth  that  were 
merely  touched  upon  in  the  first  project.  The  large  project  is  also  a  vehicle  to  introduce 


*  The  syllabus  for  the  course  is  included  as  Appendix  A. 
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and  utilize  new  concepts,  such  as  detailed  design  and  configuration  numagement  The  use 
of  a  real  customer  provides  an  opportunity  to  study  mme  complex  requirements  and 
exposes  students  to  problems  which  were  not  apparent  in  the  small  project  The  added 
ccnnplexiQ',  introduced  by  size,  real  customer,  and  intricate  requirements,  denuuids  die  use 
of  more  effective  controlling  disciplines  and  increased  attention  to  the  software  process. 

The  third  project  requires  the  students  to  perform  maintoiance  on  an  existing  large 
software  system.  To  mimic  the  typical  industrial  situation,  these  maintenance  tasks  are 
assigned  while  the  students  are  still  working  on  the  large  project.  Work  on  the 
maintenance  tasks  and  the  large  project  overlap  and  they  have  a  common  due  date.  These 
tasks  provide  yet  another  opportunity  to  revisit  and  reinforce  significant  software 
engineering  concepts,  but  this  time  from  a  maintenance  perspective.  Maintenance  is 
treated  as  a  complete  software  development  task.  Students  can  now  understand  the 
benefits  of  following  good  software  engineering  practices. 

Finally,  during  a  four-week  assessment  period,  various  formal  methods,  metrics,  and  tools 
are  applied  to  the  three  course  projects.  In  this  assessment,  both  the  processes  and  the 
products  are  evaluated  to  capture  their  strengths  and  weaknesses. 


3  The  Projects 

In  order  to  provide  an  instructional  mechanism  and  realistic  project  experience  we 
combine  two  models  from  [Shaw  91],  the  "small  group  project"  and  the  "large  project 
team"  and  supplement  this  with  a  set  of  maintenance  tasks  and  a  closing  assessment 
perixl. 


3.1  Project  1:  The  Modest/Toy  Project 

The  requirements  are  provided  and  students  ate  expected  to  specify,  design,  code,  and  test 
a  solution.  Toy  projects  recently  used  included  a  bottle  and  can  recycling  device,  an 
automated  fire  and  security  alarm  system,  a  kiosk  vending  machine  system  and  an  EMS- 
91 1  telephone  exchange.^  The  toy  project  is  scheduled  for  weeks  2  duough  6  of  the  first 
semester.  Since  work  must  begin  quickly,  controlling  disciplines  are  imposed  upon  the 
teams  with  minimum  justification  at  this  point  For  example,  students  are  immediately 
introduced  to  various  lifecycle  elements  (scheduling,  project  organization,  configuration 
management  quality  assurance,  and  verificaticm  and  v^idation  techniques)  by  "living 
them"  but  only  later  are  these  topics  formally  addressed  in  lectures.  While  the  project  is 
implemented  in  a  language  familiar  to  the  student,  Ada  specifications  are  intn^uced  in 
high-level  design. 

These  projects  involve  minimal  logical  complexity  so  that  the  students  might  devote  their 


^  See  Appendix  B  for  some  examples  of  such  projects. 
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attention  to  the  details  of  the  design  and  develqnnent  of  the  software.  Students  are  asked 
to  mimic  a  waterfall  lifecycle.  Teams  are  limited  to  four  to  six  members  each  and  we 
have  found  that  instructors  can  successfully  manage  up  to  three  different  toy  projects. 
Keeping  track  of  the  details  of  more  than  three  simultaneous  projects  imposes  a 
considerable  burden  without  any  benefit  Of  course  this  means  that  for  larger  classes 
multiple  teams  will  be  working  independently  on  the  same  project.  There  are  some 
educational  benefits  to  having  several  teams  attempting  the  same  project. 

A  democratic  team  organization  is  used  for  toy  jntjjects.  At  this  point  in  the  course,  the 
instructor  has  inadequate  knowledge  of  individual  student's  project-oriented  skills  to  be 
able  to  place  them  in  other  organizational  models.  Because  each  project  is  relatively 
small,  students  approach  it  as  individuals  in  an  ad  hoc  fashion.  Careful  professcmal 
management  is  required  to  minimize  this  mistake.  As  a  means  of  tracking  progress  and 
focusing  their  efforts,  a  software  project  management  plan  (SPMP)*,  including  scheduled 
product  reviews  and  deliverables,  is  provided.  Hiis  software  project  management  plan 
applies  equally  well  to  all  of  the  toy  projects. 

Due  to  time  constraints,  we  strongly  recommend  that  die  professor  serve  as  the  user  for 
these  projects.  As  the  user,  the  instructor  must  assume  a  naivete  about  computing  and 
only  answer  questions  from  the  user  perspective.  We  have  found  that  it  is  helpful  to 
declare  which  role  -customer  or  professor-  is  being  assumed  at  any  given  time  (e.g. 
during  requirements  clarification  and  formal  reviews  of  deliverables),  lliis  is  necessary 
to  resist  "professorial  micro  management"  of  projects.  This  over-management  problem 
is  further  minimized  by  the  involvement  of  odier  faculty  in  roles  such  as  user,  customer, 
staff,  and  reviewer. 

In  order  to  encourage  meeting  deadlines,  we  require  regular  team  meetings.  To  help 
students  who  have  not  experienced  task  oriented  meetings,  we  provide  a  task  oriented 
team  meeting  report  form^.  We  use  this  form  to  describe  how  to  control  and  track  tasks. 
Completed  team  meeting  reports  are  required  at  the  beginning  of  each  week  and  any 
common  problems  are  disc’issed  with  the  class.  Later  this  material  is  revisited  in 
discussions  of  project  status  reports  and  assessment  techniques. 

The  team  meeting  reports  also  serve  as  an  early  warning  system  for  a  variety  of  personnel 
problems.  Even  at  Ais  early  stage,  students  sometimes  shirk  their  responsibilities.  We 
recommend  team  sizes  of  six  students:  if  one  or  two  students  fail  to  contribute,  or  leave 
the  team,  it  can  still  successfully  function. 

During  this  project,  students  are  introduced  to  Ada  through  a  "program  reading 
methodology"  [Deimel  90]  using  several  artifacts  developed  especially  for  the  course.  At 
this  point  Ada  is  used  only  as  a  specification  language.  We  have  found  John  Herro's 


*  A  sample  modest  project  management  plan  is  contained  in  Appendix  C. 

*  A  sample  team  meeting  report  form  is  contained  in  Appendix  D. 


7 


shareware  tutorial.  The  Interactive  Ada  Tutor*,  to  be  useful  as  a  self-paced  introduction 
to  Ada.  As  the  toy  project  nears  completion,  a  large  project  for  a  real  customer  is 
introduced. 

The  deliverables  from  each  team's  project  include  a  requirements  analysis  document,  a 
system  design,  the  outline  of  a  test  plan  which  is  traceable  to  the  requirements,  test  cases, 
meeting  reports,  and  an  implement^  system. 


3.2  Project  2:  The  Extended  Project 

Beginning  with  an  initial  request  from  a  "real  customer",  students  are  expected  to 
complete  all  aspects  of  a  solution,  from  requirements  engineering  (elicitation,  analysis,  and 
specification)  through  implementation.  This  {Moject  begins  in  week  five  of  the  first 
semester  and  extends  through  week  eleven  of  the  second  semester.  Analysis  and  design, 
up  through  Ada  specifications,  are  completed  by  die  end  of  the  first  semester  with  detailed 
design,  coding,  and  testing  to  follow  in  the  second  semester. 

Several  items  introduced  in  project  one  are  revisited  and  expanded  upon  here,  including 
reviews,  controlling  techniques,  software  development  standards,  Ada  as  a  software 
development  tool,  and  development  team  organizations. 

Internal  project  reviews  are  emphasized  [Bruegge  91].  The  SPMP  for  the  extended 
project  requires  reviews  at  appropriate  places.  For  example,  students  experience  for  the 
first  time  a  formal  requirements  review  in  the  presence  of  a  customer.  The  schedule 
includes  time  for  them  to  modify  their  documents  based  on  the  reviews.  Students  are 
uncomfortable  reviewing  the  work  of  their  peers  and  uncomfoitable  presenting  their  work 
to  peers.  We  address  these  two  problems  in  several  ways.  The  reviews  are  highly 
structured  by  providing  the  students  with  genera!  guidelines  for  a  review  process  and 
specifications  for  the  content  of  preliminary  and  detailed  designs'.  We  have  found  that 
it  also  helps  to  have  another  faculty  member,  who  is  carefully  coached  to  assume  an 
attitude  of  constructive  criticism,  participate  in  the  reviews. 

In  some  cases  we  have  multiple  reviews  on  the  same  day  for  teams  which  have  an 
obvious  vested  interest  in  the  other  team's  work.  This  interest,  even  if  generated  out  of 
self-defense,  guarantees  careful  prior  attention  to  the  material  being  reviewed.  For 
example,  the  preliminary  user  manual  review  and  the  preliminary  requirements  review  are 
scheduled  for  the  same  day.  These  reviews  also  provide  ample  opportunity  for  "planned 
spontaneity"  on  the  part  of  die  instructor.  The  multiple  review  iqiproach  insures  that  odier 
viewpoints  are  heard  and  prompts  an  apparently  spontaneous  discussion  of  viewpoint 
analysis  and  resolution. 


*  Useful  introductory  Ada  toob  include:  (Herro  S8],  [Berdamin  91],  and  [Boocli93]. 

^  A  sample  project  management  plan  for  extended  projects  is  in  Appendix  E. 

*  The  review  guMeiines  and  formats  for  detailed  and  preliminary  des^  are  contained  in  Appendix  F. 
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A  tool  to  help  students  overcome  their  concerns  witfi  reviews  is  an  educational  materials 
package  from  the  Software  Engineering  Institute.  The  package  includes  a  video-tqx 
"Scenes  of  Software  Inspections"  and  discussion  aids.  [Deimel  91]  In  less  than  20 
minutes,  students  see  several  dramatizations  of  common  pitfalls  in  fonnal  reviews.  The 
presentation  makes  the  pitfalls  and  the  problems  they  generate  obvious  to  the  students. 
Each  dramatization  is  intended  to  be  followed  by  a  discussion  of  how  to  avoid  these 
pitfalls.  This  discussion  reduces  anxiety  about  reviews  and  develops  an  appreciation  of 
appropriate  review  roles  and  behavior.  The  students  are  required  to  attend  at  least  one 
formal  review  in  our  graduate  software  engineering  program. 

While  Ada  was  introduced  in  the  high  level  specification  of  project  one.  it  is  now  used 
as  a  requirements  specification  and  design  tool.  It  is  also  the  implementation  language 
for  the  extended  project.  Following  our  spiral  approach,  the  program  reading 
methodology  is  continued.  The  examples  and  classroom  exercises  provided  go  into 
greater  depth.  In-class  discussion  of  Ada  syntax  is  minimized  and  there  is  a  continued 
reliance  on  self-paced  Ada  tutorial  materials,  laboratory  experiences,  and  the  Ada 
Language  Reference  Manual  [ANSI/MIL-STD-181Sa,  1983]. 

We  now  justify  the  controls  which  were  imposed  in  the  toy  project.  Recognized 
standards,  such  as  DOD,  NASA,  or  IEEE  models,  are  fonnally  introduced  and  are 
required  for  all  project  documents  and  procedures.  The  size  and  complexity  of  the  current 
project  helps  students  appreciate  the  importance  of  all  aspects  of  the  standards,  both 
managerial  and  technical,  in  controlling  lx)th  process  and  product.  The  use  of  accepted 
controlling  techniques  is  also  reinforced. 

The  project  team  organization  changes  dramatically  for  this  project.  Rather  than  multiple 
projects  with  democratic  teams,  the  entire  class  is  organized  to  work  on  a  single  project 
and  students  assume  roles  on  various  functional  teams,  e.g.,  requirements,  configuration 
management,  testing,  design,  and  programming.  Several  of  these  teams  start  work 
immediately  following  the  client  request. 

New  concepts  are  also  introduced  in  project  two,  including  rigorous  controlling  techniques 
such  as  configuration  management,  formal  test  plans,  team  walkthroughs  and  inspections, 
a  matrix  organization  requiring  inter-team  and  intra-team  communication,  verification  and 
validation,  software  quality  assurance,  and  requirements  elicitation. 

Configuration  management  is  enforced.  A  configuration  management  plan  is  developed 
by  a  student  selected  as  configuration  manager.  This  plan  is  developed  and  presented  to 
the  class  for  review.’  The  revised  plan  is  automated  and  in  place  prior  to  the  development 
or  submission  of  any  other  configuration  items.  From  this  point  on,  all  documents 
submitted  for  formal  review  are  immediately  placed  under  configuration  management  and 
subsequent  modifications  must  follow  the  configuration  management  plan. 

The  careful  selection  of  a  configuration  manager  (CM)  greatly  improves  the  chances  for 
a  successful  project  The  student  selected  as  die  CM  is  placed  in  a  unique  position  among 

*  A  sample  plan  developed  by  a  student  b  attached  as  Appendix  G. 


peers.  The  instructor,  like  other  managers,  must  provide  appropriate  support  and  direction 
for  the  CM. 

Because  students  have  little  exposure  to  formal  test  design  and  testing  mediods,  we 
provide  them  with  a  sample  test  plan.  Because  the  sample  test  plan  is  keyed  to 
requirements  and  design,  we  use  h  to  intnxhice  traceability.  Most  students  view  testing 
simply  as  code  verification.  To  address  this  narrow  view  we  require  that  the  test  team 
begin  work  on  its  plan  shortly  after  requirements  analysis  is  underway.  The  degree  of 
abstraction  of  the  requirements  forces  the  test  team  to  treat  testing  as  a  complete  lifecycle 
issue. 

In  addition  to  revisiting  formal  reviews,  we  add  required  team  inspections  and 
walkthroughs  of  their  configuration  items.  These  processes  occur  during  team  meetings. 
To  give  the  widest  possible  range  of  experiences,  the  students  are  required  to  function  in 
two  different  review  roles  on  each  team  during  the  semester.  Since  each  student  is  on  two 
teams,  they  experience  four  different  roles. 

A  significant  aspect  of  this  project  is  our  employment  of  a  matrix  organization.  The  class 
is  organized  as  a  project  team  woricing  on  a  single  project.  This  resembles  a  functional 
organization.  We  make  it  resemble  a  matrix  organization  when  we  divide  the  class  into 
several  functicmal  teams,  as  described  above.  Each  student,  widi  die  excepdon  of  the  C!M, 
serves  on  at  least  two  teams  [Stuckenbruck  81].  The  correct  allocation  of  students  to 
functional  teams  is  critical  for  project  integrity.  For  example,  students  should  not  be  on 
both  the  coding  and  the  test  team.  A  critical  guideline  is  that  no  student  be  assigned  to 
two  teams  which  are  responsible  for  validating  each  other's  woric.  Many  teams  act  as 
cross  checks  on  each  other  during  development.  For  example,  if  at  all  possible  there 
should  be  a  user's  manual  team  which  meets  independently  with  the  user,  while  the 
requirements  team  meets  with  the  customer.  During  the  requirements  review  the  user's 
manual  team  can  be  used  to  help  validate  the  requirements.  Appendix  H  contains  a  model 
of  a  matrix  organizatitm  for  a  class  of  fifteen  students;  a  model  for  a  class  of  twenty-five 
students  has  also  been  developed. 

This  methodology  has  the  virtue  of  placing  many  students  in  leadership  roles.  Because 
teams  which  must  communicate  directly  with  each  other  have  no  common  students,  a 
higher  level  of  precision  is  required  in  inter-team  communications.  They  cannot  rely  on 
a  student  who  is  on  both  the  sending  and  the  receiving  team  to  clarify  document 
ambiguities.  Although  most  students  function  as  members  of  only  two  teams,  they  learn 
about  the  functions  and  products  of  the  other  teams  through  the  review  process. 

The  first  semester  takes  this  project  throu^  preliminary  design  review.  Emphasis  is 
placed  on  validation  techniques  for  requirements  and  design.  Successful  deliverables, 
specified  in  Ada,  from  this  semester  become  baseline  documents  for  the  second  semester, 
liie  second  semester  begins  detailed  design  and  continues  through  acceptance  testing. 
The  deliverables  from  the  class  and  teams  have  included:  requirements  drcuments  from 
the  requirements  team;  test  plan  and  testing  report  from  the  test  team;  configuration 
management  plan,  change  report  log,  system  build  report  from  the  configuration  manager, 
preliminary  and  detailed  design  documents  from  the  respective  design  teams;  meeting 
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repoits  from  all  teams,  and  an  implemmted  and  accepted  system. 


33  Project  3:  The  Maintenance  Project 

Another  major  component  of  the  second  semester  involves  multiple  maintenance  requests 
applied  to  a  large  Ada  artifact  This  disciplined  approach  to  maintenance  gives  the 
students  experience  needed  by  industry  iMit  rarely  achieved  in  traditioiud  software 
engineering  courses. 

Students  perform  major  nuuntenance  (including  corrective,  enhancement  and  ad^rtive 
activities)  on  an  existing  software  system.  A  maintmatKe  configuration  management  plan 
which  introduces  version  control  techniques,  and  a  maintenance  project  managemoit  plan 
is  provided.  The  maintenance  project  is  scheduled  for  weeks  six  dm>u^  eleven  of  die 
second  semester,  overlapping  die  extended  project  A  variety  of  maintenance  tasks,  like 
those  described  by  Engle,  Ford,  and  Korson  [Engle  89],  are  assigned.  Without  guidance 
students  tend  to  revert  to  "code  and  fix"  habits. 

A  new  project  organization  is  introduced  twre.  The  students  are  organized  into  chief- 
programmer  teams  [Brooks  82].  The  choice  of  chief-programmer  is  based  on  our 
knowledge  of  the  students'  skills  and  attitudes  demonstrated  on  the  odier  course  projects. 
Each  team  is  given  responsibility  for  different  maintenance  tasks  [Callis  91].  Th^  tasks, 
applied  to  a  single  laige  artifact,  require  inter-team  communication  and  stronger  change 
control,  and  introduce  the  problem  of  maintaining  ctmceptual  integrity.  This  new 
complexity  provides  new  challenges  to  die  student  CM. 

The  maintenance  project  helps  students  see  the  utility  of  controlling  techniques  during 
original  development.  By  equating  maintenance  and  development  the  students  revisit 
most  of  the  concepts  previously  discussed.  This  diird  trip  through  the  spiral  makes  it 
easier  for  them  to  woik  with  a  large  unfamiliar  artifact.  Many  students  And  this 
somewhat  surprising  and  rewarding. 


3.4  Project  Assessment  Period 

Continuous  assessment  is  integrated  into  all  project  activities  using  formal  reviews  and 
an  emphasis  on  validation  and  verificatimi  throu^out  the  life  cycle.  In  addition,  an 
extendi  closing  assessment  period  is  dedicated  to  appraising  the  strengths  and 
weaknesses  of  the  processes  and  products  discussed  and  developed  during  the  course. 

This  assessment  period,  based  on  the  final  phase  of  the  Design  Studio  course  from 
Carnegie  Mellon's  Master  of  Software  Engineering  curriculum  [Tomayko  91],  takes  place 
during  the  final  four  weeks  of  the  second  semester.  It  also  incorporates  aspects  of  the 
lessons  learned  document  of  the  NASA  software  development  standard  [NASA  86]. 
Students  leam  to  be  constructively  critical  of  their  own  work  and  to  be  realistic  abwt 
their  plans.  The  major  purpose  is  to  determine  to  what  degree  die  original  project  plans 
were  realized  and  to  discover  shortcomings  of  the  software  product  and,  pertiaps  more 


importantly,  the  software  process.  The  assessment  includes  an  analysis  of  poasiUe 
product  inqnovemoits  and  a  discussion  of  how  to  revise  the  product  accordingly. 


4  Innovatioiis  and  Advanti^  of  Ate  Approadi 

This  course  provides  a  commercial-like  environment  where  studeitts  work  on  multiide 
teams  and  team  otganizadons,  work  on  multipie  projects,  and  assume  different  roles.  Iliis 
interplay  of  models  accurately  reflects  what  die  students  will  encounter  in  industry.  This 
setting  is  also  modeled  by  using  a  variety  of  project  types,  namely,  die  "real  client"  and 
the  "toy  project"  described  by  Bruegge,  Qimg,  and  Shaw  [Bruegge  91].  Our  projects 
collectively  meet  the  standards  set  fordi  by  Shaw  and  Tomayko.  Fbr  example,  die  large 
inoject  has  a  real  customer  and  a  target  audience.  "A  project  with  a  real  client  is  die  best 
motivator"  [Shaw  91].  But  this  project  is  only  pursued  after  the  students  have  completed 
a  smdier  project  and  have  been  exposed  to  die  proper  techniques  of  software 
development  Students  will  gain  pfogramming-in-the-large  experiences  on  the  extended 
project  and  on  the  nuunterumce  project  Acquisition  of  new  domain  knowledge,  anodier 
staiidaid  set  forth  by  Shaw  and  Tomayko,  is  required  to  some  extent  in  all  three  projects. 
Fmally,  configuration  managemem  tools  appropriate  to  each  type  and  size  of  project  are 
used  [Shaw  91].  These  projects  provide  both  a  teadiing  mechimism  and  realistic  project 
experience  for  the  students. 

Multiple  modes  of  communication  are  experienced.  The  democratic  model  gives  die 
students  experience  with  a  small  project  and  intm-team  communication.  The  matrix 
organization  gives  the  students  experience  with  inter-team  communication.  The 
maintenance  project  requires  both  of  these  forms  of  communication.  All  of  these  forms 
of  communication  are  needed  by  die  successful  software  engineer. 

ETSU's  College  of  Applied  Science  and  Technology  has  an  ongoing  emphasis  on  written 
and  oral  communication  skills.  In  all  wmk  for  Ms  course,  including  reviews,  formal 
presentations  and  documents,  the  sturtents  are  required  to  adhere  to  the  standards  as 
specified  in  die  Language  Skills  Handbook  [AST  90].  Reviews  and  presentations  could 
be  videotaped  for  review,  development  and  evaluation. 

Ada  is  used  duoughout  all  course  activities.  This  is  our  students'  first  exposure  to  Ada. 
It  is  introduced  early  in  the  first  semester  using  program  reading  tedmiques  [Deimel  90]. 
For  example,  students  leam  to  read  Ada  specifications  as  illustrations  of  simple  designs. 
At  die  same  time,  Ada's  complexities  are  progressively  introduced  by  reading  odier  Ada 
examples.  In  addition  to  program  reading  and  extensive  use  of  Ada  examples,  students 
leam  to  write  high-level  design  specifications  in  Ada.  A  major  objective  is  to  have  the 
students  produce  and  validate  a  complete  Ada  specification  of  a  large  project  by  the  end 
of  the  first  semester.  Students  come  to  view  Ada  u  more  dun  an  imidementation 
language.  During  the  second  semester,  die  large  project  is  inqilnnented  in  Ada,  and 
mainterumce  is  performed  on  an  existing  Ada  software  system.  We  use  Ada  Quality  and 
Style:  Guidelines  for  Professional  Programmrs  [SPC  91]  as  our  Ada  style  guide. 
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Professional,  ethical,  and  legal  issues  are  integrated  into  bodi  the  lecture  and  laboratory 
components  of  the  course.  This  is  consistent  widi  the  recormnendations  die 
lEEE/ACM  Computer  Society  Task  Force.  Our  model  of  die  industrial  settiiig  provides 
a  context  in  which  to  discuss  a  range  of  ediical  situations  not  normally  encoumered  in 
typical  software  engineering  courses. 


5  Conclusion 

We  have  found  diis  spiral  approach  to  be  an  effective  teaching  and  learning  tool.  The 
project  framework  provides  a  series  of  passes  dirou^  die  software  development  process, 
each  pass  adding  to  a  body  of  commoi  student  experiences  to  which  sub^uent  passes 
can  refer.  By  the  middle  of  the  first  semester  students,  individually  and  in  teams,  have 
begun  accumulating  their  own  "war  stories":  some  positive,  some  negative.  This 
personalized  knowledge  provides  a  solid  base  for  more  advanced  concepts. 
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e.  integrated  Course  Structure 

Three  elements  need  to  be  carefully  integrated  to  make  this  course  a  success. 
Lectures  to  the  students  about  the  prindpies  and  concepts  of  software  engineering  must 
be  coordinated  with  their  project  tasks  and  the  labs  must  illustrate  both  lecture  materials 
arKi  clarify  project  tasks.  Our  model  for  this  integration  is  illustrated  in  the  matrix  below. 
The  Roman  numerals  in  the  first  column  indicate  the  semester,  the  numbers  in  the  lecture 
column  correspond  to  the  lecture  numbers  in  section  II  of  this  document,  the  lab  numbers 
correspond  to  the  lab  numbers  in  section  III  of  this  document,  and  the  configuration  items 
for  the  various  student  items  correspond  to  the  configuration  items  for  their  projects. 
These  configuration  items  are  described  in  section  IV  d. 


Week 

Lecture 

Lab 

Project 

1-1 

001  -  Intro,  syllabus, 
policies, overview 

1-1 

002  -  Definitions  of  SE,  software 
life  cycle,  quality,  process 

1-2 

003  •  Requirements  extraction  - 
what  &  how 

001  -  Small  project  customer 
request,  team  organization, 
project  mgmt  plan 

Begin  CI-1 

m 

004  -  Intro  to  structured  analysis, 
context  diagram,  DFDs,  data 
dictionary 

002  -  CD,  DFD  exercise 

CI-1 

005  -  Quality  standards  in 
requirements,requirements 
extraction,  DFDs 

003  -  Feedback  on  CI-1,  small 
pmject  CD,  DFD,  DD 

Begin  CI-2 

n 

006  -  Intro  to  design 

04A  -  Structure  charts 

CI-2 

1-4 

007  -  DFDs  and  DD,  structure 
charts,  test  plans  and 
requirements  traceability 

005  •  CI-3  for  small  project, 
Fee(ft}ack  on  CI-2 

Begin  CI-3 

1-4 

008  -  Design  concepts; 
architectural,  behavioral, 
procedural  design 

006  -  Additional  Feedback  on 
CI-2,  preparation  for  design 
review 

CI-3 

1-5 

009  -  Testing  and  test  plans 

007  •  Development  of  classes 
of  tests  for  small  project 

mm 

010  -  Ada  and  design;  Ada  as  a 
design  notation 

008  -  Design  review 
presentation 

CM 
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Week 

Lecture 

1-6 

oil  -  Software  makitenanoe 

1-6 

012  -  ControWng  diadptines; 
configuration  management 

1-7 

013  -  Ada  and  makitenanoe 

1-7 

014  -  Software  IMS  cycle  models 

1-8 

015  -  Requirements  elicitation, 
analysis  and  specification 

1-8 

016  -  /yda  as  a  specification  and 
maintenance  tool 

1-9 

017  •  Requirements  standards, 
2167A 

1-9 

018  -  Team  organization  and 
software  quality 

1-10 

019  -  Examination  1-1 

1-10 

020  -  Retum/discuss  first 
examination;  from  ERO's  to  Ada 

1-11 

021  -  Verification  and  validation 

1-11 

i-12 

023  -  More  on  stnjctured 
anaiyais;  process  specifications 

1-12 

024  -  Transfomi  analysis, 
transacfion  analysis 

Lab 


AAA  Pm  ■  |M| ■III,  jmm  -* — — 

UUv  *  rMQDICK  On  OOSIQn 


Project 


010 -Feedback  on  CI-5. 
preparation  for  acceptance 


Oil  -  Extended  prpject 
cuatomer  request 


012  -  Extended  project  team 
organization, . 


013  -  Peer  review  and 
acceptance  test /review 


014  -  Instnjctors  assessment 
of  small  projecLtoam 

OSOsSiQnfMOntBf  OMvMDUtO 

SPMP 


015  •  User  project  perspective 


016  •  Tasks  for  configuration 
mmager,  requirements,  user 
interim,  and  test  plan  teams 


(Examination  1-1,  cont) 


017  -  Presentalion/review  of 
configuration  management 
plan 


018  •  Preliminary  rat^jirements 
review;  Preliminary  user 
manual,  user  interface  review 


019  -  Preliminary  test  plan 
review 


020  •  Requirements  review 
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Week 


Lecture 


025  •  Coupling  and  cohesion 


026  •  Prelkninary  design  using 
functional  decornpotition;  intro  to 
object-orientation,  object  - 
oriented  analysis 


027  -  High  level  OOD,  Identifying 
objects,  Rumbaugh  notation 


028  •  Ada  packages 


029  •  Software  quality  assurance 
and  reviews 


030  •  Review  standards,  review 
checklists 


Final  Examination  1-2 


031  -  High  level  design  vs 
detailed  design;  Detailed  design 
deliverable  and  procedures 


032  -  Reuse 


033  -  Nassi-Shneiderman 
diagrams 


-  Ada:  text  I/O 


035  -  Ada:  data  types 


036  -  Ada:  statements,  control 
structures 

037  -  Ada:  structured  data  types 


-  Ada:  access  data  types 


039-Ada  procedures,  functions, 
packages. 

040- Ada  Generics 


021  -  Steer  preliminary  design 


022  -  Ada  laboratory 
environment 


023  -  Peer  review  of  extended 
project  through  preliminary 
de^n;  preliminary  design 
revi^ 


024  -  User  manual/interface 
and  test  plan  reviews 


025  -  Review  extended  project 
specifications  and  preliminary 
design  completed  in  semester 


026  -  reorganize  project  and 
teams 


027  -  Nassi-Shneiderman 
diagrams;  project  teams  work 


028  -  Detailed  design  review 


029  -  Feedback  on  detailed 
design 
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Wtek 

11-5 


_ Lecture 

041  -  Ada:  exceptions 


Lab 


Project 


042  -  Ada:  sequential  and  direct 
files _ 

043  -  Ada:  Tasks _ 

*  see  note _ 

044-Exafninatlon  li-1 _ 

045-Review  Examination  11-1 


*  see  note _ 

*  see  note _ 

046  -  Use  cases 

*see  note 

*see  note _ 

*  see  note _ 

*  see  note 

*  see  note 

*  see  note 

047  -  Implementation  languages 

048  -  Project  scheduling,  work 
breakdown  stnjctures _ 

049  -  Project  estimation. 
COCOMO 


031  -  Maintenance  project 
description,  team  organization, 
team  assignments,  assignment 
of  maintenance  1 


033  -  Maintenance  project: 
review  task  1 ,  assignment  of 
task  2 


034  -  Maintenance  project: 
review  task  2,  assignment  of 
task3 


0%  -  Extended  project: 
system  acceptance  test 


036  -  Feetftack,  instructors 
assessment  of  acceptance  test 
and  extended  projert _ 


Cl  - 10 

Cl  -11 
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Week 

Lecture 

Lab 

Pn^ 

11-15 

*  see  rwte 

038  -  Individual  and  small 
groi^  analysis  of  ethical 
scenarios 

11-15 

050  -  Course  assessment 

11-16 

Final  Examination  II 

*  NOTE  Meetings  during  these  weeks  era  used  to  meet  the  needs  of  the  0xtended 

project.  They  can  be  utilized  for  the  various  reviews,  individual  team 
meetings,  or  project  meetings  with  the  entire  class. 
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Real-Worid  Software  Enginearing 

H  LECTURES 

a.  Lactura  fomiat  and  lactura  forma. 

The  course,  covering  two  semesters,  consisted  of  formal  lectures,  discussions, 
laboratory  meetings  during  scheduled  class  meetings  and  team  meetings  outside  of 
scheduled  class  hours.  ITris  section  contains  the  lectures  in  ttie  order  in  which  they  are 
given  to  the  class.  The  two  semesters  are  divided  up  into  two  class  meetings  per  week. 
The  amount  of  time  given  to  formal  lecture  during  these  meetings  varied  depending  upon 
the  project  stage  and  students  understanding  of  and  progress  on  project  deliveradsles. 
Because  of  difficulties  in  establishing  team  meeting  times,  some  class  time  was  devoted 
to  team  meetings.  Using  class  meeting  time  in  this  way  also  offers  tfie  teacher  an 
opportunity  to  participate  in  the  meetings.  Because  the  prpjiBcts  are  the  major  scheduling 
factor  in  this  course,  it  is  important  to  be  flexible  in  terms  of  trying  to  cover  two  lectures 
every  week.  Project  reviews,  e.g.,  requirements  reviews,  design  reviews,  and  test  plan 
reviews,  are  most  effective  when  the  entire  class  participates.  These  reviews  consume 
class  meeting  time.  We  have  found  that  this  course  must  rely  m  the  students  doing  the 
required  readings.  Because  of  the  other  events  which  use  class  time,  the  student  can 
not  depend  on  the  teacher  to  cover  every  concept  during  formal  lecture. 

The  lecture  forms  provide  most  of  the  structure  for  a  lecture  and  significant  detail 
for  each  lecture.  The  form  starts  out  with  the  general  topics  for  the  lecture.  These  are 
stated  in  terms  of  the  concepts  that  are  addressed  in  the  lecture.  They  are  followed  by 
the  instructional  objectives  of  that  particular  lecture.  The  effectives  are  generally  stated 
in  terms  of  behavioral  goals.  Both  the  topics  and  the  objectives  can  be  used  in  test 
construction.  The  topics  can  be  used  to  construct  concept  questions  and  the  otfectives 
can  be  used  to  construct  performance  questions. 

We  have  used  the  SET  UP,  WARM-UP  section  to  provide  some  connection 
between  the  current  lecture  and  a  previous  lecture  or  topic.  In  some  cases,  e.g.  when 
there  are  several  lectures  on  Ada  syntax,  we  have  not  provided  such  a  connection. 

The  CONTENTS  section  contains  the  main  body  of  the  lecture.  The  topics  are 
presented  in  several  paragraphs.  The  overheads  used  for  that  lecture  follow  the 
CONTENTS  section.  As  a  topic  is  described  in  the  CONTENTS  section,  the  related 
overhead  is  named  by  using  both  the  lechjre  number  and  an  overhead  number, 
e.g.,L230H2.  This  refers  to  the  second  overhead  used  in  lecture  23.  The  overheads  are 
formatted  for  easy  duplication.  Overheads  generally  contain  examples  of  the  concept 
being  discussed  in  the  CONTENTS  section.  They  can  also  contain  sample  exercises  to 
be  done  during  class  in  order  to  reinforce  concepts  just  discussed.  The  CONTENTS 
section  contains  answers  to  the  exercises  on  the  overheads.  In  a  few  cases,  such  as  the 
sample  test  plan  overhead,  we  have  included  rather  lengthy  explanations  of  the  overhead 
in  the  form  of  instructor  notes. 


The  PROCEDURE  section  contains  subsections  on  teaching  method  and 
vocabulary  introduced.  The  presumption  is  that  the  m^or  teaching  method  is  lecture  and 
discussion  using  the  overheads  and  handouts  included  in  the  lecture  forms.  In  several 
cases  we  have  included  some  hints  at  additional  discussion  or  alternative  teaching 
methods  that  we  have  had  success  with  when  covering  a  particular  topic.  The  vocabulary 
introduced  can  be  provided  to  the  student  as  a  review  tool. 

The  RELATED  LEARNING  ACTIVITIES  section  list  the  particular  labs  which  we 
have  associated  with  a  particular  lecture.  These  labs  frequently  tie  the  theoretical  lecture 
material  to  the  practical  concerns  of  their  projects. 

There  are  two  sections  on  readings,  one  is  the  assigned  reading  in  the  textbooks 
we  use  for  the  course,  and  the  other  is  a  list  of  reading  on  the  same  topic  in  other 
software  engineering  textbooks.  If  we  cited  the  work  of  another  software  engineer  in  the 
lecture  or  overhead  material,  then  a  reference  to  that  material  is  included  in  the  reading 
list. 


On  some  occasions,  the  contents  refer  to  an  overhead  used  in  a  previous  lecture, 
e.g.,  lecture  five  refers  to  an  overhead  from  lecture  3.  When  this  happens,  the  earlier 
overhead  is  also  included  in  the  current  lecture.  Lecture  5  has  an  overhead  from  lecture 
3  in  it. 


These  forms  should  provide  you  with  an  adequate  foundation  for  structuring  you 
lectures  and  relating  them  to  the  significant  experiential  elements  of  this  course. 


b.  Lecture  Forms 
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LECTURE  NUMBER:  001 

TOPICfSI  FOR  LECTURE: 
Introduction  to  course 


INSTRUCTIONAL  QBJECTIVE(S): 

1 .  Learn  names  of  lnstructor(s).  and  other  students. 


2.  Learn  course  format,  and  course  policies. 


3.  Become  familiar  with  detailed  coume  syllabus. 


SET  UP.  WARM-UP: 

(How  to  involve  the  learner:  recall,  review,  relate) 

Try  to  set  tone  for  the  rest  of  the  course.  In  previous  courses  you  have 
covered  many  aspects  of  software  devebpment  (mention  specific  topics  such 
as  programming,  design;  mention  specific  courses).  We'll  be  looking  at  those 
as  well  as  others  as  we  consider  software  as  an  engineered  product:  some 
topics  will  be  completely  new,  some  technical,  some  non-technical. 

Realistic  team  project  experiences  will  be  integrated  into  the  course.  Since 
the  instructor(s)  and  students  will  be  spending  a  lot  of  time  together  in  the 
classroom  and  in  your  team  projects,  it  is  important  to  get  to  know  one 
another  and  to  deveiop  a  comfortable  working  atmosphere. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  want  to  give  a  sense  of  the  course;  specifically  an  overview 
including  how  class  and  project  activities  will  be  integrated,  the  course 
format,  syllabus,  and  course  policies. 


CQNIENIS: 

1 .  Introductions 

a.  Professor(s)  introduce  themselves  and  others  responsible  for 
the  course. 

b.  Have  the  students  introduce  themselves  since  they  will  be 
working  together  on  projects. 
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2.  Approach 


a.  This  is  a  two-semester  undergraduate  software  engineering 
class  that  presents  a  thorough  coverage  of  software 
engineering  while  at  the  same  time  providing  meaningful  project 
experiences  that  mimics  a  real-world  software  engineering 
process.  You  will  each  get  to  work  with  several  people  in  a 
vaariety  of  roles  on  several  projects. 


b.  We  are  taking  a  "spiral  approach"  to  the  material  presented. 
Our  first  pass  through  some  topics  will  be  exactly  that  -  a  first 
pass.  We  intend  the  depth  provided  to  be  sufficient  for 
application  to  your  first  project.  Gaps  will  be  filled  in  during 
subsequent  passes  in  the  spiral.  Similarly  there  are  many 
techniques  and  methodologies  for  analysis  and  design  but  we 
need  to  choose  specific  ones  to  apply  to  the  first  project  in  a 
timely  fashion.  So,  doni  worry  that  we're  moving  on  to  design 
and  you  feel  that  there  are  many  aspects  of  analysis  that  have 
not  been  covered. 

c.  The  understanding  that  project  activities  and  class  activities  will 
be  carefully  coordinated  is  important.  It  is  also  important  to 
make  students  aware  that  factors  in  the  success  or  failure  of 
software  projects  include  non-technical  problems  as  well  as 
technical  problems. 


3.  Distribute  and  discuss  course  policies. 

L1HD1 

a.  Course  description  and  typical  class  format. 

b.  Prerequisites. 

c.  Textbooks. 

d.  Grading  policies. 


4.  Questions  from  students? 


5.  Distribute  and  discuss  detailed  course  syllabus. 

L1HD2 

a.  Walk  through  first  week  of  the  sylabus  in  order  to  explain  all 
aspects  and  notation. 
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6.  Questions  from  students? 


PROCEDURE: 

teaching  method  and  media: 

Set  tone  for  course;  try  to  generate  enthusiasm,  team  concept,  opportunities 
to  gain  realistic  project  experience. 


Read  D.  Gotterbam  and  Robert  Riser,  "Reai-World  Software  Engineering:  A 
Spirai  Approach  to  a  Project-Oriented  Course,”  Lecture  Notes  in  Computer 
Science  750.  Software  Enoineerino  Education,  ed  Jorge  L.  Diaz-Herrera, 
Springer  Veriag  1994  pp  119-151  for  a  complete  understanding  of  the 
structure  of  this  course. 


YQcabt^lary  introducsd: 


INSTRUCTIONAL  MATERIALS: 

gverttsads: 

handouts: 

LI  HD1  Course  policies 

LI  HD2  Detailed  course  syllabus 

other: 

RELATED  LEARNING  ACTIVITIES: 

READING  ASSIGNMENTS: 

RELATED  READINGS: 
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COURSE  POLICIES 


COURSE  DESCRIPTION:  This  is  a  two-semester  software  engineering  course  that 
covers  all  aspects  of  the  software  development  process  while  providing 
participants  with  realistic  project  experiences.  Each  student  will  function  on 
multiple  project  teams  in  a  variety  of  roles  and  responsibilities. 

Project  and  lecture  activities  will  be  coordinated.  Typical  class 
meetings  will  consist  of  a  lecture  component  and  a  lab  component.  The  lab 
component  will  include  both  individual  activities  and  project  team  activities. 


PREREQUISITES:  File  Processing,  Data  Structures 


TEXT:  a)  Software  Enoineerina  4th  edition.  Sommerville 

b)  Software  Enoineerina  with  Student  Project  Guidance.  Mynatt 

c)  Ada  Minimanual.  Benjamin 


GRADING:  Tests  (2,  equally  weighted) - 40% 

Team  project  1 -  15% 

Team  project  2 -  25% 

Participation: -  20% 


Includes  attendance,  class  discussion, exercises  and  assignments, 
quizzes  on  assigned  reading,  presentation  responses 

A  passing  average  on  each  of  the  four  components  above  is  required  to  pass 
the  course. 


Individual  project  grades  will  be  based  on  3  factors:  team  project  grade,  peer 
review,  and  instructors'  perceptions  of  individual  contributions. 

All  deliverables  are  due  at  the  start  of  class  on  the  specified  due  date  unless 
otherwise  stated. 


GRADING  SCALE:  93 -100:  A 

90  -  92:  A- 


88-89:  B-i- 
83-87:  B 
80-82:  B- 


77-79:C+  0  -  54:  F 
70  -  76:  C 
65  -  69:  C- 

60  -  64:  D+ 

55  -  59:  D 
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DETAILED  COURSE  SYLLABUS 


Week  One 

Topics: 

Introduction  to  course,  course  objectives,  workshop  format,  grading  poBdes. 
and  team  projects 

Introduction  to  software  engineering.  (^aKty  software,  requirements  from  the 
viewpoints  of  the  customer  and  user,  development  of  abstract  and 
requirements  list  from  problem  specification,  and  the  example 
project 

Readings  for  class: 

Sommerville  Chapter  1  (pp.  1-5) 

Mynatt  Chapter  1  (pp.  1-27) 


Week  Two 

Topics: 

requirements  extraction 
analysis  process 

context  diagrams,  data  flow  diagrams  (DFDs).  and  data  dictionary 
Readings  for  class: 

Mynatt  Chapter  2  (pp.  44-62  and  pp.  70-74) 

Sommerville  Chapter  3  (pp.  47-63) 
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WMkThrM 


Topics: 

quality  standards  in  requirements 
requirements  extraction 

function-oriented  detign  -  more  on  DFDs  and  data  (Actionaries,  structure 
charts 


Readings  for  class: 

Sommervilie  Chapter  3  (pp.  47  -63) 
Sommerville  Chapter  10  (pp.  171-188) 
Sommervilie  Chafer  12  (pp.  219-237) 
Mynatt  Chapter  2  (pp.  44-62) 
Mynatt  Chapter  4  (pp.  143-156) 


Week  Four 

Topics: 

data  flow  diagrams  and  data  dictionaries 
structure  charts 
requirements  traceability 

Readings  for  class: 

Sommervilie  Chapter  12  (pp.  219-234) 
Sommervilie  Chapter  10  (pp.  171-188) 
Mynatt  Chapter  4  (pp.  143-156) 
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Topics: 

testing  and  test  plans 
Ada  and  design  notation 

Readings  for  class: 

Sommervilie  Chapter  19  and  22  (pp.378-388  and  pp.425-441 ) 
Mynatt  Chapter  7  (pp.276-315) 

Sommervilie  Appendix  A  (pp.607-620) 


Week  Six 

Topics: 

software  maintenance 

configuration  management  and  software  quality  assurance  (SQA) 


Readings  for  class: 

Sommervilie  Chapter  28  (pp.  533-541) 
Sommervilie  Chafer  29  (pp.  551-564) 
Mynatt  Chafer  8  (pp.  334-340) 


Week  Seven 

Topics: 

Ada  and  maintenance 
software  life  cycle  models 

Readings  for  class: 

Sommervilie  Chapter  1  (pp.  5-18) 
Mynatt  Chapter  1  (pp.  12-27) 
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WMc  Eight 


Topics: 

requirements  analysis  and  specificatton  •  client  requests,  definition  of 
requirements,  requirements  specification 
Ada  as  a  specification  tool  and  a  maintenance  tool 

Readings  for  class: 

Sommerviile  Chapter  5  (pp.  85-103) 

Mynatt  Chapter  2  (pp.  62*83) 


Week  Nine 

Topics: 

requirements  standards,  2167a 
team  organization  and  software  quality 


Readings  for  class: 

Sommerviile  Chapter  3  (pp.  45-61) 
Sommerviile  Chapter  5  (pp.  85-103) 
Mynatt  Chapter  2  (pp.  62-91) 
Mynatt  Chapter  1  (pp.  31-42) 


Week  Ten 

Topics: 

Examination  1-1 
ERDs  and  Ada 

Readings  for  class: 
None 
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IVvBK  SWOTI 


Topics: 

verification  and  validation  (V&V) 
testing 

Readings  for  class: 

SommerviHe  Chapter  19  (pp.  373-386) 
Somnnervilie  Chapter  22  (pj).  425-439) 
SommerviHe  Chapter  23  (pp.  441-454) 
SommerviHe  Chapter  24  (pp.  457-473) 
Mynatt  Chapter  7  (pp.  274-316) 


WeekTVvelve 

Topics: 

relationship  between  requirements  and  preliminary  design,  more  on  structure 
charts,  transform  analysis,  transaction  analysis,  designing  data  structures, 
abstraction 

Readings  for  class: 

SommerviHe  Chapter  2  (pp.  71-82) 

SommerviHe  Chapter  12  (pp.  222-228) 

Mynatt  Chapter  4  (pp.  62-69) 

Mynatt  Chapter  4  (pp.  143-169) 


Week  Thirteen 

Topics: 

introduction  to  object-oriented  development 
coupling  and  cohesion 

Readings  for  class: 

SommerviHe  Chapter  10  (pp.  182-188) 
Mynatt  Chafer  3  (pp.  94-130) 
Mynatt  Chapter  4  (pp.  144-150) 
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WMkFourtttn 


Topics; 

high-lsvel  object-orisntsd  design 
notation  tor  preHminary  design 
Ada  packages 

Readings  tor  class: 

Benjamin  Chapter  8  (pp.  73-78) 
SommerviHe  Chafer  10  (pp- 177-182) 
SommerviHe  Chapter  11  (pp.  194-236) 
Sommerville  Appendx  A  (pp.  610 -613) 
Mynatt  Chapter  8  (pp  364-368) 


Wdek  FHIeen 
Topics: 

Introduction  to  software  quality  assurance 
Reviews  -  walkthroughs  and  inspections 
Review  standards  and  checklists 

Readings  tor  dass: 

Sommerville  Chapter  31  (pp.  589-598) 
Mynatt  Chapter  2  (pp.  77-79) 


Week  Sixteen 

FINAL  EXAMINATION  I 
Week  Seventeen 
Topics: 

reliability  and  reuse  in  detailed  design 
The  relation  between  detailed  and  high-level  design 
detailed  design  procedures 
detailed  design  deliverables 

Readings  tor  dass; 

Sommerville  Chapter  16  (pp.  309-328) 

Mynatt  Chafer  1  (pp.  77-79) 

Mynatt  Chapter  3  (pp.  94-136) 

Mynatt  Chajster  4  (pp.  169-183) 

Benjamin  Chapters  9  and  1 2  (pp.  79-85  and  1 1 1  -1 1 7) 
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WMk  EightMn 

Topics: 

Nassi-Shneiderman  chart  notation 
Introduction  to  Ada 
I/O  in  Ada 

Readings  for  class: 

Mynatt  Chapters  (pp.  198-202) 

Benjamin  Chajiter  1  (pp.  1-10) 


Week  Nineteen 

Topics: 

Ada  data  types 
Ada  statements 
Ada  structured  data  types 

Reacfings  for  class: 

Benjamin  Chapters  2-3  (pp.  11-28) 

Benjamin  Chapter  4  (pp.  29-37) 

Benjamin  Chafer  5  (pp.  39-50) 


Week  Twenty 

Topics: 

access  data  types  in  Ada 

Ada  procedures,  functions,  and  packages 

Ada  generics 

Readings  for  class: 

Benjamin  Chapter  7  (pp.  63-72) 

Benjamin  Chapters  6  and  8  (pp.  51-62  and  73-78) 
Benjamin  Chapter  9  (pp.  79-67) 


11 


L1HD2 


Wttk  f^Mnty-om 


Topics: 

exceiJtions  and  exception  handlers  in  Ada 
sequential  and  direct  files  in  Ada 

Readings  for  dass: 

Benjamin  Chapter  10  (pp.  89-96) 

Benjamin  Chapter  12  (pp.  111-117) 


Week  *nMeiity-hvo 

Topics: 

tasks  in  Ada 

Project  meetings  *  see  note 
Readings  for  class: 

Benjamin  Chapter  11  (pp.  97-109) 


Week  Twenty-three 

Topics: 

Examination  il-1 

Hancft>ack  and  review  examination  11-1 


Week  Twenty-four 

Topics: 

project  meetings  *  see  note 

Readings  for  class: 
none 


Week  Twenty-five 

Topics: 

introduction  to  use  cases 
project  meetings  *  see  note 

Readings  for  dass: 
none 
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WMk  T^Mtnty^x 

Topics: 

prpjoct  meetings  *  see  note 


Readings  for  dass: 
none 


Week  Twenty  eeven 

Topics: 

project  meetings  *  see  note 


Readings  for  class: 
none 


Week  TWenty^ight 

Topics: 

implementation  languages  *  project  driven  choices 


Readings  for  next  class: 

Mynatt  Chapter  5  (pp.  207-235) 

Mynatt  Chajxer  6  (pp.  239-271) 


Week  Twenty-nine 

Topics: 

project  scheduling 
work  breakdown  structures 

software  project  management  (SPM)  -  planning,  scheduling 
COCOMO 

code  estimation  techniques 
Readings  for  class: 

Sommerville  Chapter  25  (pp.  477-492) 

Sommerville  Chapter  26  (pp.  495-507) 

Sommerville  Chapter  27  (pp.  511-533) 

Mynatt  Chapter  1  (pp.  17-27) 
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WMk  Thirty 


Topics: 

professionalism,  ethical  issues 
course  assessment 

Readings  for  class: 

Sommerville  Chapter  21  (pp.407-425) 
Week  Thirty-one 

FINAL  EXAMINATION  il 


*  NOTE 

Meetings  during  these  weeks  are  used  to  meet  the  needs  of  the 
extended  project.  They  can  be  utilized  for  the  various  reviews, 
individual  team  meetings,  or  project  meetings  with  the  entire  class. 
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Introduction  to  software  engineering,  quality  software,  life  cycles,  and  process 
models. 

INSTRUCTIONAL  OBJECTIVEfS): 

1 .  Understand  software  cri^s,  software  engineering,  quality  software,  and 
process  models. 

2.  Realize  the  reasons  leading  to  a  software  crisis  and  the  emergence 
of  software  engineering. 

3.  Understand  the  attributes  of  quality  software. 

4.  Recognize  the  different  viewpoints  in  the  development  of  software. 

SET  UP.  WARM-UP: 

(How  to  involve  the  learner:  recall,  review,  relate) 

The  importance  of  developing  quality  software  is  related  in  this  lecture  to  the 
projects.  The  students  begin  thinking  about  the  importance  and  role  of 
maintenance  in  the  development  of  large  software  systems.  The  concept  of 
having  a  good  process  by  which  to  develop  the  products  is  introduced. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

The  introduction  of  software  engineering  is  related  to  the  students'  previous 
experience  with  developing  software  in  other  classes.  The  idea  of 
programming  in  the  small  (previous  experience)  versus  programming  in  the 
large  (software  engineering)  is  expressed.  Emphasis  is  placed  on  the  fact 
that  software  development  In  a  real-life  situation  is  a  team  effort. 

CONTENTS: 

1 .  Software  Crisis 

L20H1 

a.  The  phrase  "software  crisis"  was  coined  in  the  late  1960's  at  a 
conference  which  was  addressing  the  problems  of  software 
development.  It  refers  to  a  series  of  problems  with  software 
development  practices  including:  the  inability  to  deliver  software  within 
budget,  on  schedule,  and  meeting  customer  needs. 

L20H2 

b.  Factors  contributing  to  the  software  crisis  are  described. 
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2. 


Software  Engineering 


L20H3 

a.  In  defining  "software  engineering"  one  must  consider  what  is  meant 
by  software  (the  products  -  the  source  code  and  the  internal  and 
external  documentation  needed  for  development,  installation, 
utilization,  and  maintenance)  and  what  is  meant  by  engineering  (the 
process  --  the  application  of  a  systematic  and  measurable  approach). 

L20H4 

b.  Software  engineering  is  needed  for  the  development  of  large,  complex 
software  systems  that  are  developed  by  teams  rather  than  individuals, 
that  require  understanding  of  the  technical  and  nontechnical  aspects 
of  software  development,  and  that  require  project  management  and 
effective  user  interface. 


3.  Quality  Software 

L20H5 

a.  The  primary  goal  of  software  engineering  is  the  production  of  quality 
software  (i.e.,  well-engineered  software). 

L20H6 

b.  The  attributes  of  quality  software  are  not  an  agreed  upon  list  of 
characteristics.  The  attributes  are  often  dependent  on  the  point  of 
view  of  the  person  involved  (e.g.,  sponsor/customer,  user,  maintainer). 
It  is  the  developers  job  to  satisfy  these  multiple  perspectives. 


4.  Software  Development  Life  Cycle 

L20H7 

a.  The  activities  required  throughout  the  life  cycle  of  a  software  system 
are  divided  into  stages  with  each  stage  having  its  own  set  of  activities. 
The  manner,  in  which  these  stages  are  organized,  is  the  process 
model.  Different  organizations  of  these  stages  lead  to  different 
process  models. 

L20H8 

L20H9 

b.  The  stages  of  the  waterfall  model.  Use  this  opportunity  to  compare 
and  contrast  the  different  stages  of  software  development. 

L2OH10 

c.  The  stages  of  the  prototype  model 
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5. 


L20H11 

Difficulties  in  Software  Development 


PROCEDURE: 

teaching  method  and  mgdia: 

It  is  important  to  touch  on  all  the  stages  of  the  life  cycle  here  to  give 
a  general  overview  of  software  developement.  The  details  of  these 
stages  will  be  presented  in  later  lectures. 


vocabulary  introduced: 
software  crisis 
software  engineering 
quality  software 
sponsor/customer 
user 

maintainer/modifier 

process  models 

requirements 

waterfall  model 

analysis 

design 

testing 

maintenance 

prototyping 


INSTRUCTIONAL  MATERIALS: 

ayerheads: 


L20H1 

L20H2 

L20H3 

L20H4 

L20H5 

L20H6 

L20H7 

L20H8 

L20H9 

L2OH10 

L20H11 


Software  crisis 

Factors  that  contribute  to  the  software  crisis 

Definitions  of  Software  engineering 

The  concerns  of  software  engineering 

Characteristics  of  quality  software  (Sommerville) 

Perspectives  on  Software  Quality  (Mynatt) 

Software  development  life  cycle 

Development  Models 

Waterfall  model 

Prototyping  model 

Difficulties  in  software  development 


READING  ASSIGNMENTS: 

Sommerville  Chapter  1  (pp.  1-5) 
Mynatt  Chapter  1  (pp.  1-27) 
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RELATED  READINGS: 

Berzins  Chapter  1  (pp.  1-3) 
Booch  Chapter  4  (pp.  27-31) 
Booch(2)  Chapter  2  (pp.  17  -20) 
Ghezzi  Chapter  2  17-40) 

Pressman  Chapter  1  (pp.  3-36) 
Schach  Chapter  3  (pp.  47-70) 
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Software  Crisis 


Problems  encountered  in  the  development  of 
latge  software  systems 


Over  Budget 
Behind  Schedule 
Failure  To  Meet  Customer  Needs 
Low  Quality 
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Factors  Contributing  To 
Software  Crisis 


Inability  to  predict  time,  effort,  and  cost  in 
software  development 

Poor  quality  of  software 

Changes  in  the  ratio  of  hardware  to  software 
cost 

Increasingly  important  role  of  maintenance 
Advances  in  hardware  and  software 
Demand  for  larger  and  more  complex  software 
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Definitions  of  Software 


IEEE:  the  systematic  approach  to  the 
development,  operation,  maintenance, 
and  retirement  of  software 

Pressman:  the  establishment  and  use  of  sound 
engineering  principles  in  order  to  obtain, 
economically,  software  that  is  reliable  and 
works  efficiently  on  real  machines. 

Fairley:  the  technological  and  managerial 

discipline  concerned  with  the  systematic 
production  and  maintenance  of  software 
products  that  are  developed  and  modified 
on  time  and  within  cost  estimates.  The 
primary  goals  are  to  improve  software 
quality  and  to  increase  productivity. 

Gotterbarn/Riser/Smith:  the  planning, 

development,  and  maintenance  of  computerized 
solutions  to  real  problems.  It  encompasses 
techniques  which  treat  software  as  an  engineered 
product  requiring  planning,  analysis,  design, 
construction,  testing,  documentation,  maintenance, 
and  management. 
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Software  engineering  concerned  with 

Technological  and  managerial  aspects  of  software 
development 

Systematic  production  and  maintenance  of 
software 

Developing  software  on  time  and  within  budget 

Assuring  software  quality 

Assuring  software  reliability 

Reducing  costs 

increasing  productivity 

Increasing  benefits 

Software  as  an  engineered  product;  attention  to 
process  as  well  as  product 
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Quality  Software 


Well-engineered 

Attributes: 

1 .  provides  required  functtonality 

2.  should  be  maintainable 

3.  should  be  reliable 

4.  should  be  efficient 

5.  shouid  offer  appropriate  user  interface 

6.  should  be  cost  effective 
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Software  Development  Life  Cycle 

The  activities  involved  in  the  production  of  a 
software  system 

The  development,  operation,  maintenance,  and 
retirement  of  software 

Development  activities  include: 

requirements  analysis  and  specifications 

design 

implementation 
system  testing 
installation 
maintenance 
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Development  Models 


Ways  in  which  the  set  of  steps  in  software 
engineering  are  appiied 

Exampies  of  software  process  models: 

waterfall  model 

prototyping 
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Waterfin  Model 


Difficulties  in 
Software  Development 

Communications 

Sequentiai  nature  of  system  deveiopment 
Project  characteristics 
Characteristics  of  personnel 
Management  issues 
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LECTURE  NUMBER:  003 


TOPICfS)  FOR  LECTURE: 

Requirements  Analysis  and  Specification 

The  importance  and  the  difficulty  of  requirements  extraction 

A  method  for  doing  requirements  extraction 


INSTRUCTIONAL  OBJECTIVEfS^: 

1 .  Understand  the  difficulty  of  gathering  and  specifying  requirements 

2.  Do  a  preliminary  requirements  abstraction 

3.  Develop  a  requirements  list 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

In  your  other  courses,  such  as  data  structures,  you  were  given  detailed 
descriptions  of  the  tasks  your  program  was  supposed  to  perform. 
Sometimes  the  overall  structure  of  the  program  was  also  provided  for  you. 
Given  such  clear  descriptions,  you  were  optimistic  about  your  ability  to 
quickly  write  programs  which  fit  the  guidelines  of  those  program  descriptions. 
This  is  not  the  way  most  programming  tasks  really  start.  Suppose  one  of 
your  friends  asked  you  to  help  her  develop  a  program  which  she  was  writing 
for  a  friend.  What  would  be  the  first  thing  you  would  ask  about  the  program? 
(List  several  of  the  responses  on  the  board.  What  you  are  looking  for  is  - 
What  is  the  program  supposed  to  do?  or  What  are  its  functions?)  The 
answer  to  this  question  about  functions  is  often  given  in  what  is  called  a 
problem  specification  of  a  client’s  reauest. 


(Learning  Label*  Today  we  are  going  to  learn  ...) 

Today  we  are  going  to  look  at  such  a  request  as  it  might  be  made  by 
someone  who  wants  a  computer  system  developed  for  them.  We  shall  see 
how  difficult  it  is  to  arrive  at  those  problem  descriptions.  These  problem 
descriptions  are  the  basis  for  the  program  descriptions  which  you  take  for 
granted.  From  this  problem  description  we  will  start  to  develop  a  list  of  the 
desired  functions.  This  list  is  sometimes  called  a  systems  requirement  list. 


CONTENTS: 

1 .  Introduce  the  concept  of  a  problem  specification 

a.  Give  class  examples  of  preliminary  problem  specifications,  e.g.. 
"Build  a  house  for  me  which  will  hold  my  children".  "Write  a 
program  which  will  control  the  temperature  in  an  incubator  for 
premature  children”.  "Build  a  dream  house  for  your  parents  - 
money  is  no  object".  "Describe  a  centralized  college  registration 
system." 
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2. 


Discuss  the  problems  with  such  specificaticns  and  discuss  why  each 
difficulty  occurs. 


a.  Vagueness  .  insufficient  detail  *  the  client  assumes  a  fcimiliarity 
with  the  problem  domain  which  you  doni  have. 

b.  Ambiguity  -  can  be  caused  by  2a,  or  ctent  is  not  aware  of  other 
possibilities,  or  the  problem  can  be  described  from  multiple 
perspective.  People  are  not  used  to  communicating  at  the 
required  level  of  precision. 

c.  Incomplete  -  functions  are  missing  because  they  were  not 
thought  of  and  combinations  of  conditions  were  not  considered. 


d.  Instability  of  description  -problem  descriptions  vary  over  time 
because  of  changing  conditions. 

e.  Discuss  the  role  of  a  professional  software  engineer  in 
attempting  to  resolve  these  difficulties. 


3.  The  goal  of  requirements  extraction  is  to  solve  these  problems  by 
completely  defining  the  problem  space-WHAT  is  required.  A  first  step 
is  to  separate  out  all  of  the  functionality  in  the  original  request. 

a.  Extracting  all  of  the  functions  in  the  client  request  helps  one 
identify  the  problems  in  the  original  request.  The  functions  can 
be  recorded  in  a  system  requirements  list  which  later  become 
part  of  a  Software  Requirements  Specification  (SRS). 

b.  This  results  in  a  complete  description  of  the  external  behavior 
of  the  product.  This  initial  list  of  the  external  behavior  of  the 
system  needs  to  be  refined  by  removing  the  difficulties  of  2a- 
2e.  This  refinement  require  communication  with  and 
participation  of  the  client. 


4.  Hints  for  developing  a  requirements  list. 

a.  In  order  to  better  understand  the  product,  try  to  visualize  it  in 
action. 

b.  List  "what  a  product  does"  rather  than  "how  it  does  it." 

c.  Understand  the  domain  in  which  the  product  operates. 
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d.  Look  for  functional  requests  by  analyzing  the  cHent  request  for 
verbs. 


5.  Distribute  the  Preliminary  Client  Request  for  the  KoFF  System. 
L3HD1 

a.  Read  through  It  with  the  class. 

b.  Ask  them  how  they  would  go  about  building  the  system  and 
direct  the  discussion  toward  building  a  rec^irements  list. 


c.  Begin  to  identify  functions  by  working  through  the  first  two 
paragraphs  looking  for  verbs  and  other  indications  of  what  the 
system  does.  Write  some  of  the  requirements  for  these 
identified  functions. 


L30H1 

d.  Show  them  the  preliminary  requirements  list  for  KoFF  and 
discuss  its  imperative  structure. 

e.  Discuss  the  adequacy  of  this  list.  Sample  problems  are 
contained  on  the  instructor's  copy  of  the  preliminary 
requirements  list.  In  discussing  the  requirements,  lead  the 
students  toward  the  need  for  testable  requirements.  (One 
technique  is  to  divide  the  class  into  groups  and  have  each 
group  review  the  adequacy  of  this  list  and  report  their  findings 
to  the  class  as  a  whole.) 


6.  Discuss  multiple  viewpoints  of  this  system. 

a.  The  customer  is  satisfied  with  many  aspects  of  the  system, 

e.g.,  the  customer  is  pleased  that  the  user  is  charged  for  a 
tape  even  before  it  is  dispensed. 

b.  The  user  is  unsatisfied  with  many  aspects  of  the  system,  e.g., 
there  is  no  person  the  user  can  talk  with  about  the  system. 


ERQCEDURE: 

teachino  method: 

Lecture/discussion  on  initial  concepts  was  followed  by  working  through 
the  Preliminary  Client  Request  for  a  video  rental  system.  A  discussion 
of  the  completeness  and  consistency  of  the  client  request  was 
followed  by  a  discussion  of  a  Systems  Requirement  List.  This  can 
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also  include  a  small  group  exercise,  in  discussing  the  requirements, 
lead  the  students  toward  the  need  for  testable  requifoments. 


vocabularv  introduced: 

cu8tomer(has  the  money) 
problem  space 
problem  specification 
requirements 

software  requirements  spectfication(SRS) 
viewpoints  (customer,  user,  etc.) 


INSTRUCTIONAL  MATERIALS: 
overheads: 

L30H1  Preiiminary  requirements  list  •  KoFF  video  rental  system 
handouts: 

L3HD1  Preliminary  client  request-video  rental  system 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

LAB001 

Cl  1 ,  for  small  project  requirements  list  is  an  exercise  on  this  subject. 

The  KoFF  preliminary  client  request  for  a  video  rental  system  can  be  used 
as  an  in-class  or  take  home  exercise.  Have  the  students  fill  in  the  missing 
details  in  the  narrative  and  discuss  the  results  in  class;  then  have  them 
develop  a  complete  requirements  list  from  their  revised  client  request. 


READING  ASSIGNMENTS: 

Sommerville  Chapter  3  (pp.  47-63) 

Mynatt  Chapter  2  (pp.  44-49)  and  (pp.  70-74) 

RELATED  READINfiS: 

Berzins  Chapter  2  (pp.  23-75) 

Ghezzi  Chafer  2  (pp.  20-29) 

Pressman  Chapter  6  (pp.  173-177) 

Schach  Chapter  6  (pp.  137-153) 
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KoFF  Preliminary  System  Requirements 


1  KoFF  shall  accept  membership  application 
information  which  includes  name, 
address,  social  security  number  and 
charge  card  information. 

2  KoFF  shall  validate  charge  cards  and 
generate  unique  RRR  club  numbers,  both 
of  which  shall  be  recorded  along  with  the 
membership  applications. 

3  KoFF  shall  charge  applicants  the 
membership  fee. 

4  KoFF  shall,  upon  request  from  a  current 
club  member,  display  a  list  of  available 
video  tapes. 

5  KoFF  shall  verify  that  member's  card  has 
not  expired. 

6  KoFF  shall  dispense  the  selected  video 
tape  to  a  valid  club  member. 


7  KoFF  shall  bill  the  customer  the  fee  for 
the  dispensed  video  tape  and  retain  the 
membership  card. 
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8  KoFF  shall  accept  returned  video  tapes 
and  return  the  membership  card  after 
billing  for  any  late  fees. 

9  KoFF  shall  make  automated  phone  calls 
when  video  tapes  are  five  days  iate. 

1 0  KoFF  shall  void  all  cards  when  a  tape  is 
ten  days  late  and  make  appropriate 
charges. 

1 1  KoFF  shall  print  membership  cancellation 
letters. 

1 2  KoFF  shall  dispense  sale  tapes  and  issue 
a  charge  to  customer's  account. 

1 3  KoFF  shail  print  rental  tracking  information 
every  two  weeks. 

1 4  KoFF  shali  print  membership  information 
on  request. 
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Automrted  Vkteo  Rwital  Svitem  PaacrinMon 
Client  Request 

Mr.  Richard  wants  a  computerized  automated  video  cassette  rental  system  which 
will  be  housed  in  unstaffed  kiosks.  These  kiosks  can  be  free  standing  in  mall 
parking  lots  or  can  be  placed  in  enclosed  shopping  malls.  This  device,  KoFF  (Kiosk 
of  Famous  Flicks),  will  accept  applics^ons  for  membership  in  Mr.  Richard's  Rapid 
Rental  club  (RRR),  display  titles  of  available  tapes,  dispense  tapes,  accept  returned 
tapes,  and  take  care  of  billings.  It  will  also  maintain  reports  of  rental  transactions 

One  becomes  a  member  of  the  club  by  entering  membership  information  on  a 
keyboard  attached  to  the  kiosk.  This  information  will  include  a  current  charge  card 
number  and  an  approval  to  automatically  charge  that  card  for  selected  items 
including  a  membership  fee  of  $  10.00.  Customers  will  be  notified  of  membership 
in  RRR  by  mail  and  will  receive  three  RRR  movie  rental  cards  and  a  unique 
personal  identification  number.  Membership  expires  on  the  expiration  date  of  their 
charge  card. 

The  kiosk  contains  250  different  tape  titles  and  1380  individual  tapes.  A  customer 
can  see  a  list  of  the  available  tapes  by  category  by  inserting  one  of  their 
membership  cards  into  the  kiosk.  The  customer  can  select  an  available  tape  and 
rental  duration.  They  will  be  charged  for  it  and  the  tape  will  be  dispensed  from  the 
tape  out  slot.  Their  card  will  be  retained  until  the  tape  is  returned  to  that  kiosk. 
When  a  tape  is  returned  to  the  tape-in  slot,  its  bar  code  will  be  scanned,  the 
customer  will  automatically  be  charged  appropriate  late  fees  and  the  membership 
card  will  be  returned.  Failure  to  return  the  tape  within  five  days  of  its  due  date 
generates  a  phone  call  to  the  customer  which  plays  a  recorded  message  about  the 
overdue  tape  and  the  accruing  late  charges.  When  the  10-day  late  limit  is  reached, 
the  customer  is  charged  for  the  late  days  and  the  cost  of  the  tape.  The  customer 
is  also  charged  a  tape  restocking  fee  and  all  of  his/her  membership  cards  are 
invalidated.  The  customer  is  notified  of  these  actions. 

The  selection  of  videos  must  be  updated.  KoFF  keeps  information  to  help  in  this 
process.  Videos  which  have  not  been  rented  for  two  weeks  are  listed  for  removal 
and  videos  which  have  been  rented  several  times  in  a  week  are  listed  for  additional 
copies.  Every  two  weeks  KoFF  sends  Mr.  Richard's  computer  a  copy  of  this  report. 
He  decides  which  tapes  to  add  and  which  to  remove.  He  updates  the  list  of  titles 
and  records  the  quantities  of  those  titles  along  with  their  identifying  bar  codes.  He 
also  assigns  the  rental  price  for  that  title.  Sometimes  instead  of  replacing  a  slow 
moving  tape,  he  simply  drops  its  rental  price  or  tries  to  sell  it.  Sale  tapes  are 
indicated  on  a  special  screen.  When  a  customer  selects  a  sale  tape,  a  record  of 
the  sale  is  made  and  the  tape  is  dispensed. 

Mr.  Richard  gets  several  reports  from  KoFF,  including  lists  of  sold  tapes,  the  rental 
activity  of  RRR  members  by  tape  title  and  tape  category  -  Adventure,  Comedy, 
Children,  Restricted,  the  rental  activity  of  particular  titles  and  copies  of  that  title,  and 
detailed  and  summary  financial  reports  of  RRR  member  accounts. 
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KoFF  Preliminary  System  Requirements  List 


1 .  KoFF  shaH  acc^  membership  application  information  which  includes  name, 
acfcfress,  social  security  number  and  charge  card  information. 

2.  KoFF  shall  validate  charge  cards  and  generate  unique  RRR  club  numbers, 
both  of  which  shcdl  be  recorded  along  with  the  membership  applications. 

3.  KoFF  shall  charge  applicants  the  membership  fee. 

4.  KoFF  shall,  upon  request  from  a  current  club  member,  display  a  list  of 
available  video  tapes. 

5.  KoFF  shall  verify  that  member's  card  has  not  expired. 

6.  KoFF  shall  dispense  the  selected  video  tape  to  a  valid  club  member. 

7.  KoFF  shall  bill  the  customer  the  fee  for  the  dispensed  video  tape  and  retain 
the  membership  card. 

8.  KoFF  shall  accept  returned  video  tapes  and  return  the  membership  card  after 
billing  for  any  late  fees. 

9.  KoFF  shall  make  automated  phone  calls  when  video  tapes  are  five  days  late. 

10.  KoFF  shall  void  ail  cards  when  a  tape  is  ten  days  late  and  make  appropriate 
charges. 

1 1 .  KoFF  shall  print  membership  cancellation  letters. 

12.  KoFF  snail  dispense  sale  tapes  and  issue  a  charge  to  customer's  account. 

13.  KoFF  shall  print  rental  tracking  information  every  two  weeks. 

14.  KoFF  shall  print  membership  information  on  request. 
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KoFF  Preliminary  System  Requirements 
(instructor's  notes) 


This  exercise  is  designed  to  illustrate  the  difficulty  of  abstracting  requirements.  It  shows  the 
importance  of  iteration.  Several  of  the  items  in  the  requirements  list  above  are  incomplete. 
They  do  not  meet  even  the  explicit  conditions  of  the  customer  request.  Some  of  the  missing 
requirements  are  listed  below.  A  good  exercise  is  to  have  the  students  fill  in  the  missing 
requirements.  Several  of  the  requirements  in  the  list  are  deliberately  ambiguous  and  others 
are  vague.  Have  the  students  resolve  the  ambiguities  and  remove  the  vagueness.  Notice  that 
none  of  the  requirements  taik  about  response  time  for  example.  There  are  several  unstated 
requirements  of  the  system.  The  client  request  does  not  even  deal  with  how  a  customer  can 
renew  their  membership.  There  is  some  opportunity  for  a  discussion  of  professionalism, 
because  the  question  of  exception  conditions  is  not  even  touched  in  the  client  request  and  not 
addressed  in  the  requirements  list.  A  discussion  about  the  professional's  responsibility  to 
produce  a  quality  system  is  usefui  here.  What  is  the  professional's  responsibility  to  help  design 
a  more  effective  system?  The  requirements  do  not  address  non-system  problems  such  as 
damaged  tapes  nor  do  they  address  detection  of  fraud  such  as  the  return  of  empty  tape  boxes 
or  the  return  of  tapes  boxes  with  blank  tapes  in  them. 

When  deveioping  DFDs  and  Structure  charts  this  exercise  can  be  easily  partitioned  into 
customer  management,  tape  management,  financial  management  and  system  reporting 
segments.  The  concept  of  design  partitioning  can  be  related  to  design  modularity  in  later 
discussions. 

The  exampie  also  provides  an  opportunity  for  the  discussion  of  some  ethical  issues.  RRR 
members  are  having  detailed  information  about  their  rental  habits  retained  by  the  system.  Is 
this  a  violation  of  their  privacy  rights?  The  system  does  not  need  to  associate  the  member's 
names  with  the  rental  of  a  video.  The  management  of  the  system  only  requires  capturing 
information  about  the  frequency  of  rental  of  a  particular  video.  Is  capture  of  this  information 
consistent  with  the  ACM  Code  of  Ethics  and  Professional  Conduct  section  II? 

The  requirements  list  below  includes  some  of  the  missing  requirements. 

1.  KoFF  shall  accept  membership  application  information  which  inciudes  name,  address, 
social  security  number  and  charge  card  information. 

A  telephone  number  is  also  needed  to  call  delinquent  accounts. 

2.  KoFF  shall  validate  charge  cards  and  generate  a  unique  RRR  club  numbers,  both  of 
which  shall  be  recorded  along  with  the  membership  applications. 

KoFF  shall  record  the  expiration  date  and  other  charge  card  information. 

KoFF  shall  produce  three  membership  cards  with  membership  information  and  print 
letters  of  acceptance  for  new  members,  or  KoFF  shall  print  the  order  to  make  and  mail 
the  cards  and  acceptance  letter. 
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(How  does  KoFF  process  appNcalions  from  members  who  have  been  rejected  fr>r  not 
returning  tapes  within  the  ten-day  grace  period?) 

3.  KoFF  shail  charge  applicants  the  membership  fee. 

4.  KoFF  Shan,  upon  request  from  a  current  club  member,  display  a  list  of  available  tapes 
and  their  rental  price. 

5.  KoFF  shall  verify  that  member's  card  has  not  expired. 

KoFF  shall  do  ?what?  if  the  card  is  expired. 

6.  KoFF  shall  dispense  selected  tape  to  a  valid  club  member. 

(How  are  tapes  stuck  in  the  dispensing  chute  handled?) 

KoFF  shall  require  the  selection  of  a  rental  (a  charge)  duration. 

7.  KoFF  shall  bill  the  customer  the  fee  for  that  video  and  retain  the  membership  card. 

8.  KoFF  shaii  accept  returned  tapes  and  return  the  membership  card  after  billing  for  any 
late  fees. 

provided  the  card  has  not  expired  during  the  rental. 

KoFF  shall  not  dispense  tapes  to  members  whose  cards  are  within  10  days  of 
expiration.  (If  card  expires  during  rental  period  then  there  is  no  way  to  charge  for  an 
unretumed  tape.) 

9.  KoFF  shaii  make  automated  phone  cails  when  tapes  are  five  days  late.  (What  is  the 
content  of  that  caii?) 

10.  KoFF  shaii  void  all  cards  when  a  tape  is  ten  days  late  ( Is  this  count  based  on  ten  24 
hour  units  or  on  ten  calendar  days?)  and  make  appropriate  charges.  (Because  cards 
are  voided,  no  one  can  access  the  system  to  return  a  tape  which  is  eleven  days  late. 
What  happens  if  they  put  the  tape  in  the  tape-in  stot?  Does  the  system  keep  the  tape 
it  already  charged  the  customer  for,  or  does  it  return  the  tape  to  the  customer?  ) 

KoFF  shall  capture  all  voided  cards  when  they  are  entered. 

1 1 .  KoFF  shall  print  membership  cancellation  letters. 

12.  KoFF  shall  dispense  sale  tapes  and  issue  a  charge  to  customers  account. 

KoFF  shaii  return  the  card  with  the  sale  tapes. 

KoFF  shaii  display  sale  tapes  when  requested  by  a  member. 
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13.  KoFF  shall  print  rental  tracking  information  svery  two  weeks. 

14.  KoFF  shall  print  membership  information  on  request. 
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LECTURE  NUMBER:  004 

TOPICfS)  FOR  LECTURE: 

Introduction  to  the  structured  analysis  model. 

INSTRUCTIONAL  OBJECTIVES: 

1 .  Understand  the  concept,  notation,  and  relationships  between: 

a)  context  diagram, 

b)  data  flow  diagrams,  and 

c)  data  dictionary. 

2.  Construct  a  context  digram  from  a  narrative  description  of  a  system. 

3.  Construct  a  first-level  data  flow  diagram  from  a  narrative  description 
of  a  system  and  a  context  diagram. 


4.  Construct  data  dictionary  items  for  the  data  flows  and  data  stores  in 
the  context  diagram  and  data  flow  diagrams. 


5.  Understand  the  concepts  of  leveling  and  balancing  in  data  flow 
diagrams. 


SET  UP.WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

Recall  our  earlier  discussions  of  the  various  activities/phases  involved  in 
software  development  and  your  work  on  developing  a  requirements  list  for 
your  projects.  What  you've  been  involved  in  is  defining  the  problem  to  be 
solved.  Requirements  analysis  and  specification  (or  just  analysis)  involves 
defining  the  problem.  In  general,  anal^ts  ask  "whaf  type  of  questions;  what 
is  the  problem  to  be  solved;  what  is  needed;  what  do  you  want  the  system 
to  do.  Analysts  extract  requirements  and  then  they  spe^  them  (write  them 
down).  Common  sense  tells  us  tiiat  we  have  to  define  a  problem  before  we 
can  solve  it;  that  forging  ahead  w^out  fully  understanding  the  problem  isn't 
an  effective  approach,  particularly  with  complex  problems.  Only  when  the 
problem  has  been  analyzed  (defined  and  specified)  does  it  make  sense  to 
start  considering  how  to  solve  it,  i.e.,  consider  design.  Designers  ask  "how" 
type  of  questions;  how  are  we  going  to  solve  the  problem. 
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(Learning  Label-  Today  vne  are  going  to  learn  ...) 

Today  we're  going  to  look  at  some  method  for  modeling  a  ayatem  in  order 
to  understand  it  and  to  develop  and  clarify  requirementa.  Specifically  we're 
going  to  look  at  atructured  analyaia. 


CQfffENTg: 

1 .  Hand  out  narrative  deacriptkKi  of  amall  college  book  ordering  example. 
L4HD1 

a.  Give  clasa  a  few  minutea  to  read  it. 

b.  Suggest  viaualizing  ayatem  "in  action”  and  imagine  what 
(phyaicai)  inventory  cards,  department  book  requests,  books 
needed  file,  book  order  form,  and  order  list  might  look  like. 
Show  overheads  of  these  to  clarify  and  assure  that  everyone 
understands  the  system. 

I  Inventory  card  L40H1 

ii  Book  request  L40H2 

iii  Books  needed  file  L40H3 

iv  Book  order  form  L40H4 

V  Order  list  L40H5 


2.  Context  diagram  (CD) 

L40H6 

Use  CD  for  small  college  book  ordering  example  to  introduce  purpose, 

concept,  notation,  and  vocabulary  related  to  CDs. 

a.  CD  is  the  first  level  of  the  structured  analysis  model. 

b.  CD  defines  system  scope;  boundaries. 

c.  CD  shows  Dfit  flows  of  information  into  and  out  of  the  system. 
The  notation  for  a  net  flow  is  a  vector  pointing  in  the  direction 
of  the  flow. 

d.  CD  shows  external  entities  (source.sink);  things  outside  the 
system  with  which  the  system  must  interact.  TTie  notation  for 
an  external  entity  is  a  rectangle.  Mynatt  calls  a  context 
diagram  a  high-level  data  flow  diagram. 
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3.  Data  dictionary  (OD) 

L40H7 

Use  DD  for  small  college  book  ordering  example  to  introduce  purpose, 

concept,  notation,  and  vocabulary  related  to  DDs. 

a.  All  data  flows  in  CD  will  be  described  in  the  data  dictionary.  As 
with  word  entries  in  a  normal  dictionary,  DD  items  are  arranged 
in  an  easily  retrievable  order  (alphabetical)  and  provide  a 
detailed  definition  of  the  item. 

b.  Discuss  entries  from  the  example  to  explain  notation  and 
relationship  between  the  CD  and  DD. 

c.  Review  Mynatt's  DD  conventions.  L40H8 


4.  Based  on  sample  CD  and  DD,  recap  how  CD  and  integrated  DD 
convey  items  above.  Note  that  the  CD  views  the  system  from  the 
outside. 


5.  Data  Flow  Diagrams  (DFDs) 

a.  Now  that  we  understand  the  boundaries  of  the  system  and  how 
it  interacts  with  external  entities,  we  can  look  inside  the  system. 
That  is,  we  can  begin  considering  what  is  needed  to  transform 
the  net  inputs  into  the  net  outputs.  The  next  level  of  modeling 
is  the  first-level  DFD. 

L40H9 

b.  Use  DFD  for  small  college  book  ordering  example  to  introduce 
DFD  purpose,  concept,  and  notation,  and  the  relationship 
between  the  CD,  DD,  and  DFD. 

i  Transform  (process,  function)  •  transforms  input  flows 
into  output  flows.  Each  transform  name  should  describe 
the  purpose  of  the  transform  and  consist  of  an  action 
verb  and  object.  The  notation  for  a  transform  is  an  oval, 
circle,  or  rounded  rectangle. 

ii  Data  flow  -  data  in  motion.  Each  data  flow  must  appear 
in  the  data  dictionary.  Each  data  flow  must  be  labeled 
unless  it  is  going  to  or  from  a  data  store  and  the  label 
would  be  the  same  as  the  data  store  name.  Dataflow 
names  are  always  nouns. 

iii  Data  store  -  data  at  rest.  Data  repository;  place  where 
data  stored;  represents  a  time  delay.  Each  data  store 
must  also  appear  in  the  data  dictionary.  Data  store 
names  are  always  nouns. 
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iv  Very  briefly  introduce  the  concept  of  leveling  by 
suggesting  that  we  could  focus  on  a  particular  transform 
of  the  first-level  DFD  and  draw  an^er  DFD  (a  child 
diagram)  represerrting  what  goes  on  inside  that 
transform,  introduce  parent-child  diagram  concept. 

V  It  is  important  to  adopt  some  consistent  naming  and 
numbering  notation  in  order  to  easily  move  between 
different  levels  of  DFDs.  Describe  convention  for 
numbering  diagrams  and  transforms  in  diagrams, 
vi  A  transform  that  cannot  to  be  broken  down  any  further 
is  called  a  primitive  transform. 

c.  There  are  two  methods  to  get  a  first  draft  of  a  first-level  DFD 
using  a  context  diagram: 

i  create  an  event  list  (an  event  is  something  to  which  the 
system  must  respond).  For  each  event,  construct  a 
transform  representing  the  system's  response  to  the 
event;  then  connect  the  transforms  adding  appropriate 
internal  data  flows  and  data  stores. 

ii  construct  a  transform  to  receive  each  of  its  input  data 
flows  and  a  transform  to  produce  each  output  data  flow. 

Note  that  these  are  simply  ways  to  get  started  by  identifying 
transforms.  Use  the  context  diagram  L40H6  to  illustrate 
method  ii.  You  should  derive  a  DFD  with  four  transforms:  Get 
department  requests,  Buy  used  books.  Receive  new  books, 
and  Generate  book  order  form.  This  model  is  not  yet 
complete  and  does  not  model  the  problem.  You  need  to  refine 
this  model  in  several  ways.  Possible  refinements  include 
adding  some  internal  data  flows  and  data  stores  to  allow 
transforms  to  interface  properly,  combining,  adding  or 
eliminating  transform  to  more  accurately  reflect  the  system. 
The  result  will  look  something  like  L40H9. 

d.  Illustrate  the  (X)ncept  of  leveling  and  establishment  of  a 
consistent  numbering^naming  convention,  by  decomposing  the 
replenish  books  transform.  Discuss  the  parent/child 
relationship  of  CD  and  different  levels  of  DDs. 

e.  Illustrate  and  give  a  brief  introduction  to  the  concept  of 
balancing  between  DFD  levels,  including  both  data  balancing 
and  functional  balancing. 

Physical  model  vs  logical  model 

a.  Physical  model  -  implementation  dependent;  useful  in  depicting 
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existing  system.  Point  out  that  our  model  of  the  small  coNege 
book  ordering  system  is  a  physical  model. 


b.  Logical  model  -  implementation  independent;  useful  in 
requirements  analysis  and  specification.  Point  out  that  during 
an^is  we  want  to  avoid  implementation  details  and  develop 
a  logical  model  of  the  system. 


PROCEDUBE: 

laaciiiaa 


The  small  college  book  ordering  example  is  used  to  introduce  ^  concepts, 
notation,  and  vocabulary  of  context  diagrams,  data  flow  diagrams,  and  data 
dictionary.  The  class  is  given  a  few  minutes  to  familiarize  themselves  with 
the  requirements  followed  by  a  short  discussion  to  assure  that  they 
understand  the  system  and  can  visualize  it  in  action.  A  CD,  then  a  DD.  and 
finally  a  first-level  DFD  for  the  system  are  provided  and  explained. 


vocabulary  introduced: 

structured  analysis 
context  diagram 
external  entities,  source,  sink 
data  flows 
data  dictionary 
data  flow  diagrams 
transform,  process,  activity 
data  store 
leveling 

parent/child  diagrams 
balancing 
data  balancing 
functional  balancing 
event,  event  list 
physical  model,  logical  model 


INSTRUCTIONAL  MATERIALS: 


overheads 

L40H1 

L40H2 

L40H3 

L40H4 

L40H5 

L40H6 

L40H7 

L40H8 


Small  College  book  ordering;  inventory  card 
Small  College  book  ordering;  Book  request 
Small  coiled  book  ordering;  Books  needed  file 
Small  College  book  ordering;  Book  order  form 
Small  College  book  ordering.  Order  list 
Context  diagram  -  Book  Order  System 
Data  dictionary  notation  examples 
Data  dictionary  conventions 
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l8t  Level  OFD  -  Book  Order  System 


harKioi^ 

L4H01  Small  ooliege  textbook  ordering  example 


RELAIEP  LEARNING  ACTIVITIES; 

(late  and  exercises) 

The  small  college  book  ordering  system  can  be  used  for  in-dass  and  lab 
exercises  to  reinforce  concepts,  vocabulary,  and  notation  for  CDs,  DDs,  and 
DFDs. 

Lab002  is  an  exercise  on  CDs  and  first  level  DFDs. 

REAPING  ASSIGNMENTS: 

Mynatt  Chapter  4  (pp.  44-62) 

RELATED  READINGS; 

Berzins  Chapter  3  (pp.  109-112) 

Ghezzi  Chapter  5  (p.  161) 

Pressman  Chapter  7  (pp.  208-211) 

Schach  Chapter  7  (pp.  162-170) 
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The  following  describes  how  the  bookstore  at  a  small  private  college  manages  the 
ordering  of  textbooks. 

The  bookstore  maintains  an  inventory  card  for  each  course  in  the  college 
catalog.  Each  inventory  card  contains  the  title,  author,  and  publisher  of  the 
textbook  currently  used.  It  also  contains  the  number  of  the  textbooks  that 
are  already  in  st(^. 

Midway  through  the  spring  semester,  each  academic  department  provides 
the  bookstore  with  textbook  infomiation  for  each  course  they  will  be  offering 
in  the  next  academic  year.  The  information  provided  is  title,  author,  and 
publisher  of  textbook  to  be  used,  and  the  expected  course  enrollment,  if 
known. 

The  bookstore  then  creates  a  Books  Needed  File  containing  the  title,  author, 
publisher,  and  number  needed  (expected  enrollment  minus  the  number  in 
stock)  for  each  book  to  be  used  in  the  next  academic  year. 

During  the  last  week  of  the  spring  semester  the  bookstore  will  buy  books 
from  students  if  the  Books-Needed-File  indicates  a  need.  Of  course,  each 
time  a  used  book  is  purchased,  appropriate  updates  are  made  in  the 
bookstore's  records. 

Over  the  summer  the  bookstore  prepares  an  Order-List  containing  the  title, 
author,  publisher,  and  number  to  be  ordered  for  each  book  that  is  still 
needed.  The  Order  List  is  then  used  to  create  an  individual  Book  Order 
Form  for  each  publisher.  These  Book  Order  Forms  are  sent  to  the 
publishers. 
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Small  College  Book  Ordering  System 
Inventory  Card 


Course; 

Textt)ook  title; 
Author; 

Publisher; 
Number  in  Stock; 
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Small  College  Book  Ordering  System 
Book  Request 


Course: 

Textbook  Title: 
Author: 

Publisher: 

Expected  Enrollment: 
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Small  College  Book  Ordering  System 


BOOKS  NEEDED  FILE 


AUTHOR 


NUMBER 
PUBLISHER  NEEDED 


(one  entry  for  book  to  be  used  next  year} 
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Small  College  Book  Ordering  System 


Book  Title 


ORDER  LIST 


AuttlfiL  Pubteher  Qtv 


{one  entry  for  each  book  to  be  ordered} 
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Small  College  Book  Ordering  System 

BOOK  ORDER  FORM 

Publisher: 

Book  Tula  Author  Quantitv 


12 


L40H5 


Book  Request  >=  Course  -i-  Title  +  Author  + 

Publisher  +  [Expected 
Enrollment] 

Course  =  Department  -t-  Course  Number 

Course  Number  =  1 12|3|  +  { digit  [3 

Digit=  1|2|3|4|5|6{7|8|9|0 

Department  =  School  Code  +  Department  Number 

Inventory  Card  =  Title  +  Author  +  Publisher  + 

InStock 

An  inventory  card  is  maintained  for  each 
course  in  the  college  catalog. 

Inventory  File  =  { Inventory  Card } 

Order  List  ={Title  +  Author  +  Publisher  +  Quantity} 
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=  is  equivalent  to  /  is  comprised  of 
+  AND  /  together  with 

I  either-or 

[  ]  one  or  more  optional  elements 

{  }  iterations  of 

I  I*  upper  limit 
{  }*  lower  limit 


'  '  literals 

Comments  may  be  added  to  a  data  dictionary. 
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LECTURE  NUMBER:  005 


TOPICfS)  FOR  LECTURE: 

Quality  standards  in  requirements 
Requirements  extraction  using  the  video  rental  example 
Development  of  DFDs  using  an  analysis  of  system  inputs  and  outputs 
Balancing  and  data  dictionaries 


INSTRUCTIONAL  OBJECTIVE(S): 

1 .  Recognize  and  correct  problems  in  a  requirements  list. 

2.  Develop  DFDs  from  a  requirements  list. 

3.  Determine  if  DFDs  are  balanced. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

As  you  learned  in  your  laboratory  requirements  project  (LabOOl)  to  develop  CI-1, 
it  is  not  easy  to  generate  a  complete  and  effective  requirements  statement. 
(Display  the  preliminary  client  request.)  L3HD1 

What  sort  of  thing  does  this  request  fail  to  do?  (Discuss  some  of  the  obvious 
failings  of  the  request,  such  as,  the  failure  to  get  a  client  phone  number  or  the 
failure  to  say  what  should  be  done  when  clients  insert  an  expired  card  into  the 
system). 

(Learning  Label*  Today  we  are  going  to  learn  ...) 

Today  we  are  going  to  learn  how  applying  some  standards  of  quality  requirements 
helps  to  clarify  the  desired  functionality  of  a  system  and  how  we  can  move  from 
a  requirements  list  to  data  flow  diagrams. 

CONTENTS: 

1.  Present  standards  for  quality  requirements.  Refer  to  failure  of  the 
Preliminary  Video  Rental  (KoFF)  Client  Request  to  meet  these  standards. 

a.  Requirements  should  be  testable. 

b.  Requirements  should  be  specific. 

c.  Requirements  should  be  feasible. 
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L5HD1 


2.  Handout  and  display  the  Revised  Client  Request  and  work  through  each  of 

the  changes  characterizing  why  they  were  made  and  how  they  relate  to  the 

above  standards. 

a.  The  addition  of  a  time  limit  for  transactions  introduces  specificity  and 
testability.  However,  the  time  limit  cannot  apply  to  things  outside  the 
system.  This  presages  the  use  of  DFDs  and  context  diagrams  to 
help  clarify  what  is  outside  of  the  system. 

b.  The  addition  of  charge  card  type  and  date  is  needed  for  the  system 
to  later  validate  the  ^rd.che^  later. 

c.  The  inclusion  of  a  requirement  for  more  detailed  customer 
information  leads  to  a  more  specific  testable  requirement. 

d.  Because  it  is  not  feasible  to  print  reports  at  the  kiosk,  report 
information  must  be  transmitted  outside  the  kiosk. 

e.  This  is  a  good  time  to  consider  whether  the  software  developer  is 
responsible  for  leaving  something  out  of  the  system  that  the  user  did 
not  disclose  to  him.  In  some  cases  the  developer  would  not 
otherwise  have  any  knowledge  that  an  item  would  be  needed  and  in 
other  cases  the  developed  might  know  of  useful  additions  to  the 
system.  Briefly  discuss  ethics  issues  and  the  developer’s 
responsibility  here. 

L5HD2 

3.  Display  the  revised  requirements  list  showing  how  the  changes  in  the  Client 

Request  are  reflected  in  the  requirements  list. 


a.  A  good  example  of  ambiguity  is  the  10-day  late  penalty.  Until  the 
word  calendar  was  added  to  requirement  10  from  the  preliminary 
requirements(L30H1)  (Now  requirement  15)  it  was  not  dear  whether 
the  requirement  referr^  to  calendar  dates  or  24-hour  clock  periods. 
Note  that  this  problem  is  pervasive.  Refer  to  additional  examples, 
e.g.  Sommerville  reading. 


4.  How  do  you  generate  DFDs  from  a  requirements  list? 

L50H1 

a.  Also  discuss  the  inputs  and  outputs  to  the  system  and  develop  a  list 
from  the  students;  then  show  overhead 

L50H2 
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b.  Using  the  input-output  list  show  them  how  to  generate  a  context 
diagram(Mynatt).  Do  only  part  of  the  list  on  the  board  and  then 
show  the  complete  context  diagram.  Relate  each  of  the  inputs  and 
outputs  back  to  the  requirements  list.  Note  how  some  inputs  may  be 
merged  under  a  single  label  and  this  is  only  revealed  by  use  of  a 
data  dictionary.  Membership  application  is  a  good  example  of  this. 

L50H3 

c.  Talk  about  the  major  functions  of  the  system  -membership  control, 
tape  control,  billing,  and  report  generation  -  as  the  initial  transforms 
of  the  DFD.  Show  the  level  one  DFD. 

L50H4 

d.  Show  the  next  level  of  the  Manage  Membership  transform  as  an 
example  of  leveling. 

e.  Revisit  the  concept  of  balancing 

i  Ask  why  the  inputs  and  outputs  for  member  management  in 
diagram  1  do  not  match  the  Inputs  and  outputs  for  member 
management  in  diagram  0.  This  shows  that  the  verification  of 
balancing  depends  on  the  data  dictionary. 

ii  Reintroduce  the  concept  of  a  data  dictionary  showing  them 
the  entry  for  "Application”  L50H5  which  consists  of  several 
elements. 

iii  Explain  to  students  that  there  are  several  reasons  for  dividing 
up  complex  data  flows.  These  reasons  include  reference  to 
some  elements  which  may  be  classified  or  privileged 
information,  or  some  other  process  may  only  look  at  one 
element 


PROCEDURE: 

teaching,  .mfllhod: 

Lecture  on  initial  concepts  is  followed  by  working  through  the  Preliminary 
Client  Request  for  a  video  rental  system.  An  interactive  discussion  of  the 
completeness  and  consistency  of  the  client  request  is  followed  by  a 
discussion  and  development  of  DFDs. 


YOcahulatyJDtrQdufifld: 

feasible 

leveling 

testable 

specificity 

INSTRUCTIONAL  MATERIALS: 

cverhaads: 
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L3HD1 

L50H1 

L50H2 

L50H3 

L50H4 

L50H5 


Preliminary  client  requeat'Video  rental  system 

System  in^  and  ou^  Ust 

Context  diaoram-video  rental  system 

Level  zero  OFD-video  rental  system  (Manage  Membership) 

Level  one  DFO  •  vkJeo  rental  system  (Man^  Membership) 

Example  data  dictionary  entry  from  KoFF  DO 


handouts: 

L5HD1  Revised  client  request  for  KoFF  automated  video  rental  system 
L5HD2  Adjustcxf  requirements  list  for  KoFF  video  rental  system 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab003  -  Building  the  CO.  OFDs.  and  DD  for  the  small  project  is  an  exercise 
on  this  subject. 


REAPING  ASSIGNMENTS; 

Sommerville  Chapter  3  (pp.  47-63) 
Mynatt  Chapter  2  (pp.  44-62) 
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Automated  Video  Rental  System  Description 

Client  Request 

Mr.  Richard  wants  a  computerized  automated  video  cassette  rental  system  which  will  be 
housed  in  unmanned  kiosks.  These  kiosks  can  be  free  standing  in  mall  parking  lots  or 
can  be  placed  in  enclosed  shopping  malls.  This  device,  KoFF  (Kiosk  of  Famous  Flicks), 
will  accept  applications  for  membership  In  Mr.  Richard's  Rapid  Rental  club  (RRR),  display 
titles  of  available  tapes,  dispense  tapes,  accept  returned  tapes,  and  take  care  of  billings, 
it  will  also  maintain  reports  of  rental  transactions. 

One  becomes  a  member  of  the  club  by  entering  membership  information  on  a  keyboard 
attached  to  the  kiosk.  This  information  will  include  a  current  charge  card  number  and  an 
approval  to  automatically  charge  that  card  for  selected  items  including  a  membership  fee 
of  $  10.00.  Customers  will  be  notified  of  membership  in  RRR  by  mail  and  will  receive 
three  RRR  movie  rental  cards  and  a  unique  personal  identification  number.  Membership 
expires  on  the  expiratior;  date  of  their  charge  card. 

The  kiosk  contains  250  different  tape  titles  and  1380  individual  tapes.  A  customer  can 
see  a  list  of  the  available  tapes  by  category  by  inserting  one  of  their  membership  cards 
into  the  kiosk.  The  customer  can  select  an  available  tape  and  rental  duration.  They  will 
be  charged  for  it  and  the  tape  will  be  dispensed  from  the  tape  out  slot.  Their  card  will  be 
retained  until  the  tape  is  returned  to  that  kiosk.  When  a  tape  is  returned  to  the  tape-in 
slot,  its  bar  code  will  be  scanned,  the  customer  will  automatically  be  charged  appropriate 
late  fees  and  the  membership  card  will  be  returned.  Failure  to  return  the  tape  within  five 
days  of  its  due  date  generates  a  phone  call  to  the  customer  which  plays  a  recorded 
message  about  the  overdue  tape  and  the  accruing  late  charges.  When  the  10-day  late 
limit  is  reached,  the  customer  is  charged  for  the  late  days  and  the  cost  of  the  tape.  The 
customer  is  also  charged  a  tape  restocking  fee  and  all  of  his/her  membership  cards  are 
invalidated.  The  customer  is  notified  of  these  actions. 

The  selection  of  videos  must  be  updated.  KoFF  keeps  information  to  help  in  this  process. 
Videos  which  have  not  been  rent^  for  two  weeks  are  listed  for  removal  and  videos  which 
have  been  rented  several  times  in  a  week  are  listed  for  additional  copies.  Every  two 
weeks  KoFF  sends  Mr.  Richard's  computer  a  copy  of  this  report.  He  decides  which  tapes 
to  add  and  which  to  remove.  He  updates  the  list  of  titles  and  records  the  quantities  of 
those  titles  along  with  their  identifying  bar  codes.  He  also  assigns  the  rental  price  for  that 
title.  Sometimes  instead  of  replacing  a  slow  moving  tape,  he  simply  drops  its  rental  price 
or  tries  to  sell  it.  Sale  tapes  are  indicated  on  a  special  screen.  When  a  customer  selects 
a  sale  tape,  a  record  of  the  sale  is  made  and  the  tape  is  dispensed. 

Mr.  Richard  gets  several  reports  from  KoFF.  including  lists  of  sold  tapes,  the  rental  activity 
of  RRR  members  by  tape  title  and  tape  category  -  Adventure,  Comedy,  Children, 
Restricted,  the  rental  activity  of  particular  titles  and  copies  of  that  title,  and  detailed  and 
summary  financial  reports  of  RRR  member  accounts. 
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KoFF  Praliminary  Syttam  Raqulraments  List 


1.  KoFF  shall  accept  membership  af^lication  information  which  includes  name, 
address,  social  security  number  and  charge  card  information. 

2.  KoFF  shall  validate  charge  cards  and  generate  unique  RRR  club  numbers,  both 
of  which  shall  be  recorded  along  with  the  membership  applications. 

3.  KoFF  shall  charge  applicants  the  membership  fee. 

4.  KoFF  shall,  upon  request  from  a  current  club  member,  display  a  list  of  available 
video  tapes. 

5.  KoFF  shall  verify  that  member's  card  has  not  expired. 

6.  KoFF  shall  dispense  the  selected  video  tape  to  a  valid  club  member. 

7.  KoFF  shall  bill  the  customer  the  fee  for  the  dispensed  video  tape  and  retain  the 

membership  card. 

8.  KoFF  shall  accept  returned  video  tapes  and  return  the  membership  card  after 
billing  for  any  late  fees. 

9.  KoFF  shall  make  automated  phone  calls  when  video  tapes  are  five  days  late. 

10.  KoFF  shall  void  all  cards  when  a  tape  is  ten  days  late  and  make  appropriate 

charges. 

1 1 .  KoFF  shall  print  membership  cancellation  letters. 

12.  KoFF  shall  dispense  sale  tapes  and  issue  a  charge  to  customers  account. 

13.  KoFF  shall  print  rental  tracking  information  every  two  weeks. 

14.  KoFF  shall  print  membership  information  on  request. 
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KoFF  Preliminary  System  Requirements 
(instructor's  notes) 


This  exercise  is  designed  to  illustrate  the  difficulty  of  abstracting  requirements.  It  shows  the 
importance  of  iteration.  Several  of  the  items  in  the  requirements  list  above  are  incomplete. 
They  do  not  meet  even  the  explicit  conditions  of  the  customer  request.  Some  of  the  missing 
requirements  are  listed  below.  A  good  exercise  is  to  have  the  students  fill  in  the  missing 
requirements.  Several  of  the  requirements  in  the  list  are  deliberately  ambiguous  and  others 
are  vague.  Have  the  students  resolve  the  ambiguities  and  remove  the  vagueness.  Notice  that 
none  of  the  requirements  talk  about  response  time  for  example.  There  are  several  unstated 
requirements  of  the  system.  The  client  request  does  not  even  deal  with  how  a  customer  can 
renew  their  membership.  There  is  some  opportunity  for  a  discussion  of  professionalism, 
because  the  question  of  exception  conditions  is  not  even  touched  in  the  client  request  and  not 
addressed  in  the  requirements  list.  A  discussion  about  the  professional's  responsibility  to 
produce  a  quality  system  is  useful  here.  What  is  the  professional’s  responsibility  to  help  design 
a  more  effective  system?  The  requirements  do  not  address  non-system  problems  such  as 
damaged  t^s  nor  do  they  address  detection  of  fraud  such  as  the  return  of  empty  tape  boxes 
or  the  return  of  tapes  boxes  with  blank  tapes  in  them. 

When  developing  DFDs  and  Structure  charts  this  exercise  can  be  easily  partitioned  into 
customer  management,  tape  management,  financial  management  and  system  reporting 
segments.  The  concept  of  design  partitioning  can  be  related  to  design  mixlularity  in  later 
discussions. 

The  example  also  provides  an  opportunity  for  the  discussion  of  some  ethical  issues.  RRR 
members  are  having  detailed  information  about  their  rental  habits  retained  by  the  system,  is 
this  a  violation  of  their  privacy  rights?  The  system  does  not  need  to  associate  the  member's 
names  with  the  rental  of  a  video.  The  management  of  the  system  only  requires  capturing 
information  about  the  frequency  of  rental  of  a  particular  video.  Is  capture  of  this  information 
consistent  with  the  ACM  Code  of  Ethics  and  Professional  Conduct  section  II? 

The  requirements  list  below  includes  some  of  the  missing  requirements. 

1 .  KoFF  shall  accept  membership  application  information  which  includes  name,  address, 
social  security  number  and  charge  card  information. 

A  telephone  number  is  also  needed  to  call  delinquent  accounts. 

2.  KoFF  shall  validate  charge  cards  and  generate  a  unique  RRR  club  numbers,  both  of 
which  shall  be  recorded  along  with  the  membership  applications. 

KoFF  shall  record  the  expiration  date  and  other  charge  card  information. 

KoFF  shall  produce  three  membership  cards  with  membership  information  and  print 
letters  of  acceptance  for  new  members,  or  KoFF  shall  print  the  order  to  make  and  mail 
the  cards  and  acceptance  letter. 

(How  does  KoFF  process  applications  from  members  who  have  been  rejected  for  not 
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returning  tapes  within  the  ten-day  grace  period?) 

3.  KoFF  shall  ^arge  applicants  the  membership  fee. 

4.  KoFF  shall,  upon  request  from  a  current  dub  member,  display  a  list  of  available  tapes 
and  their  rental  price. 

5.  KoFF  shall  verify  that  member's  card  has  not  expired. 

KoFF  shall  do  ?what?  if  the  card  is  expired. 

6.  KoFF  shall  dispense  selected  tape  to  a  valid  dub  member. 

(How  are  tapes  stuck  in  the  dispensing  chute  handled?) 

KoFF  shall  require  the  seledion  of  a  rental  (a  charge)  duration. 

7.  KoFF  shall  bill  the  customer  the  fee  for  that  video  and  retain  the  membership  card. 

8.  KoFF  shall  accept  returned  tapes  and  return  the  membership  card  after  billing  for  any 
late  rees. 

provided  the  card  has  not  expired  during  the  rental. 

KoFF  shall  not  dispense  tapes  to  members  whose  cards  are  within  10  days  of 
expiration.  (If  card  expires  during  rental  period  then  there  is  no  way  to  charge  for  an 
unreturned  tape.) 

9.  KoFF  shall  make  automated  phone  calls  when  tapes  are  five  days  late.  (What  is  the 
content  of  that  call?) 

10.  KoFF  shall  void  all  cards  when  a  tape  is  ten  days  late  ( is  this  count  based  on  ten  24 
hour  units  or  on  ten  calendar  days?)  and  make  appropriate  charges.  (Because  cards 
are  voided,  no  one  can  access  the  system  to  return  a  tape  which  is  eleven  days  late. 
What  happens  if  they  put  the  tape  in  the  tape-in  slot?  Does  the  system  keep  the  tape 
it  already  charged  the  customer  for,  or  does  it  return  the  tape  to  the  customer? ) 

KoFF  shall  capture  all  voided  cards  when  they  are  entered. 

1 1 .  KoFF  shall  print  membership  cancellation  letters. 

12.  KoFF  shall  dispense  sale  tapes  and  issue  a  charge  to  customers  account. 

KoFF  shall  return  the  card  with  the  sale  tapes. 

KoFF  shall  display  sale  tapes  when  requested  by  a  member. 

13.  KoFF  shall  print  rental  tracking  information  every  two  weeks. 
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14.  KoFF  shall  print  membership  information  on  request. 


I 

I 

I 


9 


L3HD1 


DFD  Preparation 


System  inputs: 

Member's  name  and  address. 

Member's  phone  number. 

Member's  charge  card  data. 

Membership  card  information. 

Membership  card. 

Tape  seiection. 

Rentai  duration. 

Returned  Tape 

Internai  processes: 

Generate  card  numbers. 

Validate  card. 

Retain  expired  cards. 

Not  process  cards  within  10  days  of  expiration. 

Void  all  cards  of  those  who  transgress  the  lateness  limit. 

System  outputs: 

Membership  acceptance  information. 

Membership  billing  to  charge  company. 

Available  rentai  videos  to  the  monitor. 

Videos  for  sale  to  the  monitor. 

Sale  and  rental  tapes. 

Membership  card. 

Mr.  Richard's  financial  reports. 

Dispensed  tape 
Dunning  phone  call 
New  member  letter 
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KoFF  Automated  Video  Rental  Syatem 
Context  Diagram 


KoFF  Automated  Video  Rental  System 

Diagram  0 
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KoFF  Automated  Video  Rental  System 

Diagram  1 


Excerpt  from  KoFF  DP 


Data  Dictionary: 
Application  = 

Address  = 

Name  = 


Name  +  Address  +  Phone  number  + 
Charge  card  type  +  Charge  card 
number  Card  Expiration  Date. 

Street-address  +  City-State  + 
Zipcode. 

First  Name  +  Last  Name. 
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Automated  Video  Rental  System  DescriQtlon 
REVISED*  Client  Request 

Mr.  Richard  wants  a  computerized  automated  video  cassette  rental  system  which  will  be 
housed  in  unmanned  kiosks.  These  kiosks  can  be  free  standing  in  mall  parking  lots  or  can  be 
placed  in  enclosed  shopping  malls.  This  device,  KoFF  (Kiosk  of  Famous  Flicks),  will  accept 
applications  for  membership  in  Mr.  Richard's  Rapid  Rental  dub  (RRR),  display  titles  of  available 
tapes,  dispense  tapes,  accept  returned  tapes,  and  take  care  of  billings,  it  will  also  maintain 
reports  of  rental  transactions.  To  assure  customer  satisfaction,  aii  transactions  with  the 
customer  shouid  take  piece  in  iess  than  90  seconds. 

One  becomes  a  member  of  the  club  by  entering  membership  information  on  a  keyboard 
attached  to  the  kiosk.  This  information  will  include  a  current  charge  card  number  type  and 
expiration  date  and  an  approval  to  automatically  charge  that  card  for  selected  items  including 
a  membership  fee  of  $  10.00.  Customer  information  wiii  aiso  inciude  customer's  name, 
maiiing  address  and  teiephone  number.  Customers  will  be  notified  of  membership  in  RRR 
by  mail  from  Mr.  Richard's  office  and  will  receive  three  RRR  movie  rental  cards  and  a  unique 
personal  identification  number.  Membership  expires  on  the  expiration  date  of  their  chaige  card. 

The  kiosk  contains  250  different  tape  titles  and  1380  individual  tapes.  A  customer  can  see  a 
list  of  the  available  tapes  by  category  by  inserting  one  of  their  unexpired  membership  cards 
into  the  kiosk.  Expired  cards  are  captured  by  KoFF.  Customers  with  more  than  10  days 
to  expiration  can  continue  to  interact  with  KoFF.  The  customer  can  select  an  available 
tape  and  rental  duration.  They  will  be  charged  for  it  and  the  tape  will  be  dispensed  from  the 
tape  out  slot.  Their  card  will  be  retained  until  the  tape  is  returned  to  that  kiosk.  When  a  tape 
is  returned  to  the  tape-in  slot,  its  bar  code  will  be  scanned,  the  customer  will  automatically  be 
charged  appropriate  late  fees  and  the  membership  card  will  be  returned.  There  is  a  hardware 
device  that  determines  if  the  correct  tape  was  returned  undamaged.  Failure  to  return  the 
tape  within  five  days  of  its  due  date  generates  a  phone  call  to  the  customer  which  plays  a 
recorded  message  about  the  overdue  tape  and  the  accruing  late  charges.  When  the  10-day 
late  limit  is  reached,  the  customer  is  charged  for  the  late  days  and  the  cost  of  the  tape.  The 
customer  is  also  charged  a  tape  restocking  fee  and  all  of  his/her  membership  cards  are 
invalidated.  KoFF  shaii  transmit  membership  canceiiation  ietters  to  Mr.  Richard's 
computer.  KoFF  shaii  capture  aii  invaiidated  cards.  The  customer  is  notified  of  this. 

The  selection  of  videos  must  be  updated.  KoFF  keeps  information  to  help  in  this  process. 
Videos  which  have  not  been  rented  for  two  weeks  are  listed  for  removal  and  videos  which  have 
been  rented  several  times  in  a  week  are  listed  for  additional  copies.  Every  two  weeks  KoFF 
sends  Mr.  Richard's  computer  a  copy  of  this  report.  He  decides  which  tapes  to  add  and  which 
to  remove.  He  updates  the  list  of  titles  and  records  the  quantities  of  those  titles  along  with  their 
identifying  bar  codes.  He  also  assigns  the  rental  price  for  that  title.  Sometimes  instead  of 
replacing  a  slow  moving  tape,  he  simply  drops  its  rental  price  or  tries  to  sell  it.  Sale  tapes  are 
indicated  on  a  special  screen.  When  a  customer  selects  a  sale  tape,  a  record  of  the  sale  is 
made,  the  tape  is  dispensed  and  the  membership  card  is  returned. 

Mr.  Richard  gets  several  reports  from  KoFF,  including  lists  of  sold  tapes,  the  rental  activity  of 
RRR  members  by  tape  title  and  tape  category  ,i.e..  Adventure,  Comedy,  Children,  Restricted, 
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the  rental  activity  of  particular  titles  and  copies  of  thM  title,  and  detailed  and  summary  financial 
reports  of  RRR  member  accounts. 

*  Bold  items  reflect  revisions 
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KoFF  Adjusted  Requirements  list 


1.  KoFF  shall  accept  membership  application  information  which  includes  name, 
address,  social  security  number  and  charge  card  information.  A  teleplione 
number  is  also  needed  to  cell  delinquent  eceounts. 

2.  KoFF  shall  validate  charge  cards  and  generate  a  unique  RRR  dub  numbers,  both 
of  which  shall  be  recorded  along  with  the  membership  applications. 

3.  KoFF  shall  record  the  expiration  date  and  other  charge  card  information. 

4.  KoFF  shall  transmit  the  order  to  make  and  mail  the  cards  and  acceptance 
letter  to  Mr.  Richard's  computer. 

(How  does  KoFF  process  applications  from  members  who  have  been  rejected  for  not 

returning  tapes  within  the  ten-day  grace  period?) 

5.  KoFF  shall  charge  applicants  the  $10  membership  fee. 

6.  KoFF  shall,  upon  request  from  a  current  dub  member,  display  a  list  of  available 
tapes  and  their  rental  price. 

7.  KoFF  shall  verify  that  a  member's  card  has  not  expired. 

8.  KoFF  shall  retain  the  card  If  the  card  la  expired. 

9.  KoFF  shall  dispense  a  selected  tape  to  a  valid  dub  member. 

(How  are  tapes  stuck  in  the  dispensing  chute  handled?) 

10.  KoFF  shall  require  the  selection  of  a  rental  (a  charge)  duration. 

11.  KoFF  shall  bill  the  customer  the  fee  for  the  selected  video  and  retain  the 

membership  card. 

1 2.  KoFF  shall  accept  returned  tapes  and  return  the  membership  card  after  billing  for 
any  late  fees,  provided  the  card  has  not  expired  during  the  rental. 

13.  KoFF  shall  not  dispense  tapes  to  members  whose  cards  are  within  10  days 
of  expiration.  (If  card  expires  during  rental  period  then  there  is  no  way  to 
charge  for  an  unretumed  tape.) 

14.  KoFF  shall  make  automated  phone  calls  when  tapes  are  five  days  late.  (What 
is  the  content  of  that  call?) 


15.  KoFF  shall  void  all  cards  and  make  appropriate  charges  when  a  tape  is  ten 
calendar  days  late.  (Because  cards  are  voided,  no  one  can  access  the  system 
to  return  a  tape  which  is  eleven  days  late. ) 
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16.  KoFF  shall  capture  all  voided  cards  when  they  are  entered. 

17.  KoFF  shall  tranamlt  membership  cancellation  letters  to  Mr.  Rtehard'e  oompuler. 

18.  KoFF  shall  dispense  sale  tapes  and  issue  a  charge  to  customer's  account  within 
1  minute  of  the  start  of  the  transaction. 

19.  KoFF  shall  return  the  card  wKh  the  sale  tapes. 

20.  KoFF  shall  display  sals  tapes  whan  raquastad  by  a  mambar. 

21.  KoFF  shall  transmit  rental  tracking  information  for  two-weeks  activity  when 
requested  by  Mr.  Richard. 

22.  KoFF  shall  transmit  membership  information  upon  request  from  Mr.  Richard. 


Bold  items  reflect  revisions. 

Parentheses  indicate  questions  for  class  discussion  on  potential  weaknesses  in  the 
requirements. 
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1.  OistinguMt  b0tw«en  anatysit  and 

2.  IdentHy  kay  dasign  goals. 

3.  Know  the  general  ir^juts  and  outputs  of  design. 

4.  Understand  the  purpose  and  notation  of  structure  chartt. 

5.  Understand  fan-ln,  fan-out.  oouping.  and  cohesion  as  stnjchirsd 
design  criteria. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

During  the  first  class  we  discussed  the  dHtorent  activities  in  the  software  Me 
cyde  and  some  models  of  the  Its  cyde.  Some  aspects  of  design  have  been 
touched  upon  in  introdudory  programming  classes,  and  possttrly  some  other 
courses.  Some  area«r  of  the  topic  wM  either  be  covered  in  more  depth  and 
other  areas  are  new  material. 

We  are  taking  a  "spiral  approach"  to  the  material.  Our  first  pass  through 
some  topics  will  be  exactly  that  -  a  first  pass.  We  intend  the  depth  provided 
to  be  suffident  for  application  to  your  first  project  Gaps  will  be  fiNed  in 
during  subsequent  passes  in  the  spiral.  Similarly  there  are  many  techniques 
and  methodologies  for  analysis  and  design  but  we  need  to  choose  specific 
ones  to  apply  to  the  first  project  in  a  timely  fashion. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

L20H8  L60H1  L60H2 

In  our  second  lecture  we  considered  various  activities  of  the  software  Rfe 
cyde.  The  waterfall  model  shows  the  stages  of  software  development.  We 
have  discussed  requirements  analysis  and  you  have  experienced  this  in  your 
small  projects.  Today  we  ate  going  to  introduce  the  concept  of  design  and 
how  it  relates  to  requirements. 


1.  What  is  design? 

a.  Whereas  analysis  defines  the  problem  apaoe,i.e..  what  needs 
are  to  be  met,  design  considers  iKtiK  to  sofos  the  problem;  pggt 
to  meet  the  requirement. 
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b.  Design  involves  estabHshing  the  overall  system  architecture; 
the  components  and  the  relationship  between  the  components 

c.  Identifies  how  to  meet  the  spedfied  requirements  subject  to  the 
stated  goals  and  constraints.  Point  out  how  customer  goals 
(non-funcUonal  requirements)  can  lead  to  different  solutions. 

L60H3 

d.  Preliminary  design  is  the  identification  and  selection  of  major 
system  components  and  how  they  relate.  ( A  black  box  view.) 

L60H4 

e.  Detailed  design  is  a  refinement  of  preliminary  design  in  which 
the  internal  aspects  of  the  components  and  the  interfaces  are 
detailed.  (A  white  box  view.) 

f.  in  practice,  we  iterate  between  requirements  analysis  and 
design.  Realisticaliy  there  is  often  not  the  dean  break  between 
these  activities  that  is  implied  by  the  life  cycle.  Typically  it  is 
not  possible  to  completely  spedfy  the  system  and  proceed  to 
design  knowing  the  requirements  are  stable. 

L60H5 

g.  Key  design  goals.  Design  is  intended  to  solve  the  custopmers 
needs.  Other  important  aspect  of  design  that  are  frequently 
forgotten  relate  to  both  the  developer  and  the  customer. 
Software  should  be  designed  so  that  it  is  easily  testable  and 
has  components  that  can  potentially  be  revised.  Designing  with 
future  maintenance  in  mind  is  also  important. 


Structure  charts 

a.  Discuss  the  analogy  of  structure  charts  to  architectural 
blueprints  for  a  house.  These  are  design  documents:  produced 
after  the  requirements  have  been  determined.  The  blueprints 
show  the  architecture  of  the  house:  the  components  (rooms, 
heating  system,  plumbing,  etc)  and  the  relationship  between 
the  components. 

b.  Structure  chart  is  one  way  to  depict  a  software  design. 

L60H6 

Note  notation  and  information  conveyed: 

i  Components  (modules)  represented  as  rectangles. 

ii  Purpose  of  each  component  is  conveyed  in  its  name. 

iii  Interfaces  between  components  (data  couples,  control 
couples)  are  show  as  vectors  with  labels.  Data  couples 
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start  with  an  open  circle  and  end  with  an  arrowhead. 
Control  couples  start  with  a  filied-in  circle  and  end  with 
an  arrow  head.  (Mynatt  pg  152) 
iv  Hierarchy  (make  analogy  with  organization  chart) 
showing  who  calls  who,  who  reports  to  whom.  As  a 
familiar  analogy,  use  segments  of  school's  organization 
chart  depicting  President  at  levei-1 ,  and  VP's  at  ievei-2. 
Take  VP*Academic  Affairs  down  to  Dean  level,  chair 
level,  and  faculty  level.  As  precursor  to  fan-in/fan-out, 
without  using  the  terms,  ask  questions  such  as:  What 
would  you  think  about  the  organization  if  there  were  37 
vice-presidents  reporting  to  the  president?  If  there  was 
1  dean  reporting  to  a  VP?  If  there  was  a  lower  level 
function  that  was  called  upon  by  many  different 
functions  at  higher  levels? 

Design  measures/criteria  (use  L60H6) 

a.  Fan-in  -  A  component's  fan-in  is  the  number  of  higher  level 
components  that  call  upon  it;  its  bosses.  (Calculate  Normal 
Deductions  has  fan-in  of  2.) 

b.  Fan-out  -  A  component's  fan-out  is  the  number  of  components 
that  it  caiis  upon  its  immediate  subordinates.  (Issue  pay  checks 
for  all  employees  has  a  fan-out  of  4.) 

c.  Coupling  is  a  measure  of  dependency  between  components. 
A  design  goal  is  to  minimize  coupling  by  eliminating 
unnecessary  dependencies.  Intuitively,  loosely  coupled 
components  are  desirable  because  their  independence  makes 
them  more  maintainable  and  have  a  greater  chance  of  being 
reusable. 

d.  Cohesion  is  a  measure  of  the  internal  strength  of  a  component; 
of  how  well  the  elements  within  a  component  contribute  a 
single  well-defined  purpose.  A  design  goal  is  to  maximize 
cohesion.  intuitively,  highly  cohesive  components  are 
desirable.  Analogies  with  familiar  team  and  team  concepts  are 
useful  here.  For  example,  athletic  teams  that  are  cohesive  (all 
of  members  work  well  together;  often  teams  with  lesser  talent 
are  more  successful  than  teams  with  greater  talent). 

e.  Note  that  strong  cohesion  and  loose  coupling  are  related;  they 
have  an  inverse  relationship.  Minimizing  coupling  (the 
dependencies  between  components)  will  result  in  more 
cohesive  components.  Conversely,  improving  (increasing  level 
of)  cohesion  will  reduce  (improve)  coupling. 
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4.  There  are  many  different  design  strategies  and  methodologies:  for 
example,  structured  design  methods  and  object-oriented  design 
methods.  While  we  will  be  talking  about  some  gerteral  design 
principles,  we  will  use  structured  de  jgn  in  the  first  project  and  thus 
will  be  adopting  some  specific  structured  design  notation  and  method. 

PROCEDURE: 

tBttshlno  method: 

The  intent  at  this  point  is  to  briefly  introduce  design  in  general  and  structured 
design  in  particular.  A  sample  structure  chart  for  a  familiar  type  of  system 
is  used  as  a  vehicle  to  describe  the  notation  to  be  used  and  how  to  use  it  in 
design.  Ask  the  students,  near  the  end  of  the  lecture,  how  the  structured 
model  helps  in  achieving  the  design  goals  identified  in  1g  above. 

vocabulary  introduced: 
design 

preliminary  design 
detailed  design 

general  design  goals  (maintaine^ility,  reusability,  ease  of  testing) 

structured  design 

object-oriented  design 

structure  chart 

fan-in 

fan-out 

coupling 

data  couples 

control  couples 


cohesion 

INSTRUCTIONAL  MATERIALS: 

overheads: 

L20H8 

Waterfall  model 

L60H1 

Software  requirements  analysis 

L60H2 

Software  specifications 

L60H3 

Preliminary  design 

L60H4 

Detailed  design 

L60H5 

Key  design  goals 

L60H6 

Example  structure  chart 

haodouts: 

RELATED  LEARNING  ACTIVITIES: 

(labs  exercises) 

Lab004  Discussion  questions  aimed  at  verifying  understanding  of  the 
content  and  notation  of  structure  charts  are  helpful.  For 
example,  provide  a  structure  chart  similar  to  that  in  OHS  and 
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ask  about  the  hierarchy,  interface?  and  coupling  between 
particular 

modules,  fan-in  and  fan-out  for  specific  modules,  and 
oohesiveness  of  specilic  modules. 


Sommervilie  Chapter  10  (pp.  171-189) 


Sommerville  Chapter  12  (pp.  219-237) 


Mynatt  Chapter  4  (pp.  143-156) 


Ghezzi  Chapter  4  (pp.  61-1 15) 
Pressman  Chapter  10  (pp.  315-359) 
Schach  Chapter  10  (pp.  289-331) 
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Software  Requirements  Analysis 


Input 

Client  request 

Process 

Identify  customer  needs 

Output 

Software  requirements  document 
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Software  Specifications 


Input 


Software  requirements  documents 


Process 


Analyze  and  refine  software 
requirements  into  testable 
specifications 


Output 


Software  specifications  document 
Test  plan/test  procedures 
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Preliminary  Design 


Input 

Software  specifications  document 

Process 

Generate  a  software  architecture  to 
satisfy  the  specifications 

Output 

Preliminary  design  document 
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Detailed  Design 


Input 

Preliminary  design  document 

Process 

Refine  each  module  in  the  preliminary 
design  into  detailed  logic 

Output 

Detailed  design  representation 
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Key  Design  Goals 


Maintainability 
Reusability 
Ease  of  testing 
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Example  Structure  Chart 
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LECTURE  NUMBER:  007 


TQPtO(S)  FOR  UeCTURE: 

Data  flow  diagrams  and  data  dictionaiies 
Structure  charts  and  data  coupling 
Requirements  traceability 


INSTRUCTIONAL  OBJECTiVEfSi: 

1 .  Recognize  and  correct  problems  in  data  flow  diagrams(DFDs). 

2.  Develop  data  dictionaries  for  DFDs. 

3.  Develop  structure  charts. 

4.  Understand  relationship  between  test  plans  and  requirements. 

SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

(Write  ”WAYCY"  on  the  board.)  In  some  of  your  other  programming  classes 
you  are  given  a  program  specification  and  are  expected  to  immediately  start 
coding.  This  method  of  software  development  has  unfortunately  become  a 
software  development  methodology  and  has  led  to  the  acronym  WAYCY  -- 
Why  aren't  you  coding  yet?.  As  we  have  seen  with  the  video  rental  system, 
a  clear  understanding  of  the  system  to  be  developed  requires  an  iterative 
process.  Recently  we  developed  a  DFD  for  the  video  rental  system.  Are  we 
ready  to  code  yet?  (Display  the  context  diagram  for  KoFF  L50H2.)  There 
are  still  many  questions  that  can  be  asked  about  the  video  rental  system  we 
are  using  as  an  example.  Does  this  diagram  represent  the  needed  detail 
to  build  the  video  rental  system?  What  is  the  information  needed  in 
"Membership  application"?  To  determine  that  information  we  need  to  know 
the  content  of  this  data  flow.  This  requires  the  development  of  a  data 
dictionary  and  the  development  of  an  overall  system  architecture  for  the 
system. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  are  going  to  learn  how  the  data  dictionary  is  related  to  the  analysis 
of  requirements  in  a  data  flow  diagram  and  how  it  is  related  to  the 
development  of  a  system  structure  chart,  which  is  one  possible 
representation  of  a  system  architecture. 

CONTENTS: 

1.  Review  the  iterative  nature  of  the  software  development  process  and 
discuss  how  changes  made  later  in  a  system  are  more  difficult  to 
correct  and  more  error  prone. 

L50H3 

2.  Display  the  first-level  DFD  for  the  video  rental  system.  Ask  them  if  the 
diagram  is  a  complete  and  correct  representation  of  the  system. 
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L5HD2 

a.  Select  requirements  one  at  a  time  and  trace  it  through  the 
DFD.  The  completeness  can  be  examined  by  checking  the 
requirements  list  and  the  data  dictionary. 

L7HD1 

b.  Correctness  can  be  evaluated  only  when  the  system  is  dearly 
specified.  Hand  out  a  complete  data  dictionary  and  examine 
several  entries.  Review  the  format  adopted  for  this  dass  for  a 
data  dictionary  L40H7,  L40H8 


3.  Another  way  to  see  if  you  deariy  understand  a  system  is  to  design  a 

structure  chart  for  it. 

a.  A  strudure  chart  is  not  tied  to  a  particular  type  of  computer  or 
programming  language.  It  is  a  high-level  design  of  the  system 
showing  the  system  architecture. 

b.  There  are  many  methods  for  deriving  strudure  charts.  One  is 
to  divide  the  system  into  its  major  tasks.  Show  the  first  level 
of  the  strudure  chart  L70H1.  Be  sure  to  spedfy  that  this  is 
just  one  version  of  a  strudure  chart. 

c.  Discuss  how  "Enroll  Members"  and  "Seled  Tapes"  on  the 
strudure  chart  ga^er  the  major  inputs  to  the  system.  Show 
how  the  major  internal  processing,  induding  the  dispensing  and 
accepting  of  tapes,  has  been  relegated  to  a  single  process. 


4.  The  concentration  of  internal  processing  in  one  component  (3.c  above) 
can  be  used  to  introduce  some  issues  about  design  induding 
complexity  and  testing. 

a.  Ask  the  studente  if  having  a  single  component  doing  all  the 
internal  processing  is  a  good  design.  You  are  looking  for  them 
to  be  concerned  about  the  complexity  and  the  possibility  for 
error. 

b.  Discuss  the  concept  of  a  central  transform  and  how  to  reduce 
complexity.  Redisplay  the  first-level  DFD  for  the  video  rental 
system  (L50H3)  and  ask  them  where  most  of  the  information 
transformation  takes  place(Manage  Tape  inventory).  Discuss 
how  the  complexity  might  be  reduced  by  separating  out 
functions.  Return  to  the  discussion  of  the  structure  chart  as  a 
way  to  determine  how  to  remove  some  complexity. 
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5.  Work  through  the  lower  levels  of  the  structure  chart  and  review  the  concept 
of  data  coupling. 

a.  Work  through  the  "Enroll  Members"  structure  chart.  L70H2 
Use  the  data  dictionary  to  determine  what  information  needs  to 
be  passed  to  each  component.  Explain  how  this  approach 
enables  a  clear  division  of  labor.  The  goal  of  the  "Enroll 
Members"  component  is  to  do  one  thing;  to  develop  and  pass 
the  "new  member  letter"  to  the  rest  of  the  system. 

b.  Do  a  high  level  examination  of  the  "Select  Tapes"  component. 
Show  overhead  L70H3  which  just  lists  the  sub^mponents  of 
"Select  Tapes".  Use  this  to  reinforce  the  concept  of  passing  a 
data  item  to  the  rest  of  the  system  by  tracing  a  members 
request  for  a  tape  into  the  lower  levels  of  the  structure  chart. 

c.  Carry  the  concept  of  passing  information  to  the  rest  of  the 
system  to  the  discussion  of  "Manage  Tape  Inventory".  Would 
the  complexity  of  "Manage  Tape  inventory"  be  reduced  if  it 
didnl  really  transform  anything  but  was  simply  a  switch  for  data 
going  to  and  from  other  processes?  Display  the  "Manage  Tape 
Inventory"  overhead  L70H4  and  work  through  the  Late 
Processing  component. 


6.  Introduce  the  notion  of  testing  at  this  stage  of  the  life  cycle. 

a.  Test  plans  can  be  developed  which  are  related  to  the 
requirements  list.  Test  plans  should  contain  details  on  specific 
tests  to  be  conducted,  tests  can  then  be  traced  to  certain 
requirements  at  any  point  in  the  software  development  life 
cycle.  This  is  called  requirements  traceability.  And 
requirements  can  then  be  trac^  to  specific  tests. 

b.  Testing  can  be  designed  which  is  directly  related  to  the 
structure  chart.  Even  before  any  coding  is  started,  tests  which 
specify  the  interface  requirements  between  system  components 
can  be  specified  and  added  to  the  test  plan. 


PROCEDURE: 

teaching  method  : 

Discuss  the  details  of  video  rental  DFD  by  asking  questions  which 
require  the  use  of  the  data  dictionary.  Then  present  a  method  for 
building  structure  charts  by  dividing  a  system  into  inputs,  processes, 
and  outputs. 
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OOfnpl9l0f166S 

oorrsctness 

requiremerits  traceability 
data  coupling 
teat  plan 

INSTRUCTIONAL  MATERIALS: 
gvBrtwadg: 

L5HD2  Revised  Requirements  List 

L50H4  Context  diagram-video  rental  system 

L50H5  Level  one  DFO-video  rental  system 

L70H1  Top-level  structure  chart-video  rental  system 

L70H2  Stmcture  chart  for  enroll  members 
L70H3  Structure  chart  for  select  tapes 

L70H4  Structure  chart  for  manage  tape  inventory 

handouts: 

L7HD1  video  rental  system  data  dictionary 


RELATED  LEAR 
(labs  and  exercises) 


ACTIVITIES: 


Lab  005  Cl  3,  for  small  project  is  an  exercise  on  this  subject. 


READING  ASSigNMENTS: 

SommerviUe  Chapter  12  (pp.21 2-234) 

RELATED  READINGS: 

Berzins  Chapter  3  (pp.  109-114) 
Ghezzi  Cha^r  7  (pp.  394-400) 
Pressman  Chapter  11  (pp.  367-391) 
Schach  Chapter  10  (pp.  291-299) 
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ENROLL  NEW  meilBERS 
STRUCTURE  CHART 


MANAGE  TAPE  INVENTORY 
STRUCTURE  CHART 


Data  Dletlonaiy  for  KoFF  Example 


access  number «  digit  -i-  digit  +  digit  •i'  digit 
barcode-{digH  ^ 

billing  confirmation  «  not  ok  |  ok  confirmation  number 

billing  data  «  member  card  number  -i-  unique  personal  identification  number 
•»-  charge  amount 

blank  >  "  *  blank  character  * 

box  number  >  { digit 

cancellation  letter «  customer  name  +  customer  address  +  member  card 

number 

category  «  Adventure  |  Comedy  |  Children  |  Restricted 

cents  amount «  digit  -i-  digit 

charge  amount  >  dollar  amount  + -i-  cents  amount 

charge  card  number «  { digit 

charge  card  #  «  charge  card  number 

charge  card  type  «  American  Expre^  |  Discover  |  Master  Card  |  Visa 
charge  confirmation  >  not  ok  |  ok  h-  confirmation  number 
city  ■  { letter 

confirmation  -  ok  |  not  ok 
confirmation  number  -  { digit 

customer  address  «  street  -i-  dty  state  code  *  zip  code 
customer  confirmation  >  not  ok  |  ok  confirmation  number 
customer  name  >  { letter }” 

customer  validation  ■  charge  card  type  -t-  charge  card  number  •»-  expiration 
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date 


day«  digit  •!>  digit 

dispensed  membership  card  ■  *  returned  membership  card  * 

dispensed  tape  «  *  returned  tape  * 

digit  -  0|1|2|3|4|5|6|7|8|9 

doiiar  amount  >  {digit}^o 

duration  >  digit  -t-  digit 

expiration  date  •  month  +  'r  +  day  -t-'t  ^  year  *  iast  two  digits  oniy 
invaiid  card  #  «  member  card  number 

ietter.  A|B|C|D|E|F|G|H|l|J|K|L|MiN|0|P|Q|R|S|T|U|V|W|X|Y|Z|a|b|cid|e|fig|h| 

i|jik|i|m|n|o|p|q|r|s|t|u|v|w|x|y|zlbiank 

iist  of  rental  tapes  >  {  movie  info }  *  display  selectable  tapes  to  rent  * 

list  of  sales  tapes  -  {  movie  info }  *  display  selectable  tapes  to  buy  * 

member  card  number  >  digit  4  digit  *  digit  digit  -i-  digit 

member  info  «  charge  card  type  -t-  charge  card  number  expiration  date  * 
customer  name  -f-  customer  address  +  telephone  number  + 
unique  personal  identification  number  +  member  card  number 
+  member  status 

member  number  >  member  card  number  +  unique  personal  identification  number 
member  status  -  valid  |  invalid 

membership  application  «  charge  card  type  -f  charge  card  number  +  expiration 

date  -t-  customer  name  customer  address  +  telephone 
number 

membership  card  ■  *  physical  card  in  system  * 

membership  fee  ■  charge  amount 

membership  fee  charge  «  charge  card  type  +  charge  card  number  -i-  expiration 

date  +  membership  fee 
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month  >  digit  +  digit 

movie  info  >  movie  name  +  bar  code  +  category  +  movie  rating  -i-  quantity  4- 
transaction  type -f  price 

movie  name  >  { ietter }” 

movie  rating  »  G  I  PG  |  PG-13  |  R  |  NC-17 1  X 

movie  request »  movie  name  transaction  type  -i-  [  duration  ] 

new  member  letter «  customer  name  +  customer  address  +  unique  personal 

identification  number  +  member  card  number  -f 
expiration  date 

prefix  -  digit  -t-  digit  -i-  digit 

phone  call  -  *  call  to  customer  about  late  tape  * 

price  >  charge  amount 

quantity  «  digit  -t-  digit 

rental  info  «  member  card  number  +  mo\ae  info 

reports  «  *  see  KoFF  description  for  this  information  * 

returned  tape  >  *  tape  brought  back  into  KoFF  * 

sales  info  «  member  card  number  movie  info 

state  code  -  letter  -t-  letter 

status  change  >  member  card  number  -t-  invalid 

street  -  street  number  +  street  name  |  'P.O.  Box'  +  box  number 

street  name  » { letter 

street  number  >  { digit 

tape  charges  «  charge  card  type  +  charge  card  number  •>>  expiration  date  * 

charge  amount 

tape  selected  «  bar  code 

telephone  number  -  prefix  access  number 
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transaction  type  >  rental  |  sale 

unique  personal  identification  number  -  { digit 

year  >  digK  +  digit 

zip  code  «  digit  +  digit  +  digit  +  digit  +  digit  [  +  digit  +  digit  •••  digit  +  digit  ] 
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LECTURE  NUMBER:008 


TOPiCCS)  FOB  .LECTURE: 

General  conoopis  of  design 
Architectural  design 
Behavioral  design 
Procedural  design 

INSTRUCTIONAL  QBJECTIVEfSk 

1 .  Recognize  different  classifications  of  design. 

2.  Understand  different  design  stages. 

3.  Recognize  different  design  techniques. 


SET  UP.  WARM-UP: 

(How  to  involve  learner:  recall,  review,  relate) 

Once  we  have  developed  a  compi^  set  of  requirements  we  have  to 
transition  from  the  question  of  what  is  wanted  -  the  solution  space-  to  an 
anaiysis  and  presentation  of  how  we  can  achieve  what  the  client  wants.  This 
process  is  called  "Design"  and  it  has  several  stages,  just  as  requirements 
has  several  stages,  ^mmerviiie  characterized  design  as  "...  a  creative 
process  which  requires  experience  and  some  flair  on  the  part  of  the 
designer."(  page  176)  Aithough  there  is  some  creativity  required,  the 
transition  from  the  problem  sps^  to  the  solution  space  is  a  major  step  which 
requires  some  significant  preparation  and  is  accomplished  in  a  series  of 
sts^es. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  are  going  to  take  a  broad  look  at  design  and  divide  it  into  some 
manageable  stages. 


CONTENTS: 

1 .  The  design  stage  of  the  life-cycle. 

a.  The  product  of  design  shows  how  a  system  can  meet  the 
user's  needs  as  spi^ied  in  the  requirements.  Whereas 
analysis  defines  the  problem,  the  design  shows  how  to  solve 
it.  The  design  is  the  basis  for  the  implementation.  Part  of  this 
design  product  is  the  user  interface. 

L80H1 

b.  The  goals  of  design  have  many  similarities  to  the  goals  of 
requirements  devetopment:  clarity,  completeness,  correctness, 
functionality,  and  continued  usability.  The  de^n  must  be 
feasibility  from  both  a  technical  and  a  practical  perspective. 
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c.  Design  is  a  multi-staged  process  in  the  software  development 
life  cycle.  The  first  stage  of  design  -  High  Level  or  Preliminary 
Design  -  identifies  the  major  component  of  a  system  and  the 
relations  between  them.  The  second  stage  of  design  -  Low 
Level  or  Detailed  Design  describes  the  internal  characteristics 
of  these  components.  Low  level  design  also  develops  utility 
components  of  the  system.  Explain  the  ambiguity  in  "Design”. 
It  is  both  a  process  consisting  of  High  level  and  low  level 
design  and  a  product  of  the  life  cycle  which  is  used  for 
implementation. 


d.  All  implemented  systems  which  have  any  longevity  will  have  to 
change.  A  standard  of  well-designed  software  is  its  ease  of 
maintainability.  Parnas  emphasized  "Design  for  change!"  as 
a  mark  of  quality  design. 

e.  When  we  design  we  should  think  of  potential  multiple 
applications  of  software.  We  add  to  Parnas'  standard  for 
quality  "Design  for  reuse". 

L80H2 

There  are  three  distinct  components  of  software  design. 

a.  Architectural  design  -  definition  of  the  software  structure; 
components  and  their  relationships.  This  step  requires  a  clear 
choice  of  how  the  system  will  be  decomposed  into  components, 
e.g.,  modules  in  structured  design,  objects  in  object-oriented 
design.  When  decomposing  into  components,  considerations 
include: 

i  design  goals:  modularity,  low  coupling 

ii  functional  considerations:  major  system  tasks 

iii  data  storage  activities 

iv  major  system  objects 

Shows  the  environment  and  its  interfaces,  and  constraints. 

b.  Behavioral  design  -  a  description  of  the  way  a  system  responds 
to  specific  inputs.  This  is  a  picture  of  the  state  a  system  will 
adopt  given  a  description  of  the  system's  current  state  and  its 
current  input.  A  good  example  of  state  transitions  is  an 
elevator.  If  an  elevator  is  on  the  floor  above  you  and  you  press 
the  up  button.  The  elevator  changes  to  the  moving  down  state. 
If  the  elevator  is  on  a  floor  below  you,  then  pressing  the  same 
up  button  causes  the  elevator  to  change  to  the  moving-up 
state.  This  shows  how  the  same  input  can  result  in  two 
different  outputs. 
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c.  Functional  design  -  a  system  as  a  set  of  entities  performing 
relevant  tasks,  and  decomposed  into  relevant  components. 
This  view  indudes  a  description  of  the  tasks  performed  by  each 
entity  and  the  interaction  of  the  entity  with  other  entities  and 
with  the  environment.  The  architectural  view  is  an  elaboration 
of  functional  design,  showing  interfaces  and  information  flows. 

3.  All  three  types  are  important  for  a  complete  design.  The  order  will 
vary  depending  on  the  type  of  system  being  developed.  These 
dassifications  provide  a  model  for  ways  to  partition  the  design 
process.  For  example  the  development  of  a  telephone  switching 
system  might  start  with  a  behavioral  design. 

4.  In  an  effort  to  achieve  darity  of  design,  each  design  type  has  its  own 
separate  language  or  design  notation  which  can  be  divided  into  a 
language-like  notation  and  a  graphical  notation.  L80H3 

a.  Architectural-structure  charts,  pseudo-code 
L80H4 

b.  Behavioral-  Harrell  state  charts,  control  specifications 

c.  Functional-  data  flow  diagrams,  process  specifications, 
implementabie  components 

d.  Ada  as  a  textual  notation  can  be  used  for  all  three  components 
of  software  design. 

i  can  be  abstractly  stated 
li  not  a  la^e  step  to  implementation 


5.  The  process  of  design  can  also  be  divided  into  different  stages 

a.  Preliminary  -  the  first  step  in  a  progressive  transformation  of 
the  requirements 

i  audience  -  customer,  developer 

ii  notation  -  graphical:  structure  charts,  object  diagrams 

text:  prose  descriptions 

b.  Detailed  -  each  of  the  components  is  designed  in  detail, 
algorithms  and  data  structures  are  selected  which  are 
consistent  with  ttie  interface  established  in  preliminary  design. 

i  audience  -  design  team,  coders,  technical  staff 

ii  notation  -  graphical:  Nassi  Shneidermann  charts 

text:  Formal  specifications,  pseudo-oode, 
PDLs,  Ada 
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wchiltoturil  dssiQn 
cwnwsa  OMiQn 
behavioral  deaion 
functional  deeign 
Moduia  IniBffaoa  Language 
■ormai  ipeonicaBona 
prelkninary  deeign 
solution  apace 
user  imerfaoe  design 
Harrell  State  Transition  diagrams 
control  specifications 
process  specifications 


INSTRUCTIONAL  MATERIALS: 

L80H1  Goals  of  requiraments 

L80H2  Distinct  classifications  of  design 

L80H3  Examples  of  design  notation 

L80H4  Example  of  a  transition  state  diagram 

handoutB! 


RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 

Lab006  Feedback  on  Ci  2 


READING  ASSIGNMENTS: 

SommerviHe  Chapter  10  (pp.  171-168) 
Mynatt  Chapter  4  (pp.  143-156) 


RELATEDBEADINQS: 

Berzins  Chapter  4  (pp.  207-216) 

Booch  Chapter  2  (pp.  35-36) 

Booch(2)  Chapter  2  (pp.  25-26) 

Ghezzi  Chapter  4  (f^.  61-115) 

Pressman  Chapter  10  (pp.  315-359) 

Robert  Rrth.  at  al  *A  Classification  Scheme  for  Softwrare  Development 
Methods."  TR.  SEi/CMU-67-TR-41.  November  1967 
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COMMON  QOALS  OF  IIGQIIINa»fT8 

ANDDE8I0N 


Clear 

Complete 

Correct 

Functional 

Testable 

Maintainable 

Reusable 

Feasible 
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DISTINCT  COMPONENTS  OF  DESIGN 


a.  Architectural  -  definition  of  the  software 

structure 

i  Design  goals: 

Modularity,  low  coupling 

ii  Functioned  considerations: 

Major  system  taste 

iii  Data  storage  activities 

iv  Major  system  objects:  object  oriented 

b.  Behavioral  -  a  systems  as  a  set  of 

transitions  between  states 


c.  Functional  -  a  system  as  a  set  of  entities 

performing  relevant  taste 
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*■'  .  •  "  ■  ■1"^.  ■  . . —  ■  . .  "  Ml 

ExampiM  of  Design  Notation 


Ctel 


iii^r  H[*]i 


Architectural 

Behavioral 

Functional 


Qnphte  Mfltitton  T  _e  x  t 

Notation 

Structure  charts  Paeudo-Code 

Harrell  state  charts  Control 

spedflcations 

Data  Row  Diagrams  Process 

specifications 


7 


L80H3 


8 


LECTURg  NUMBER:009 


TQPiCfS^  FOR  LECTURE! 
iMling 
Test  plans 


INSTRUCTIONAL  QBJECTIVErS^: 

(indIcats  learner  behavior  expected  or  learning  outoome) 

1.  Understand  the  different  types  of  code  testing. 

2.  Be  able  to  develop  a  test  plan. 


SgT  UP.  WARM>UP: 

(How  to  involve  learner:  recall,  review,  reiate) 

We  normaily  think  of  testing  as  oniy  relevant  to  the  coding  aspects  of  a  system 
and  so  we  do  not  pay  much  attention  to  testing  untii  the  coding  phase  has  already 
started. 

As  you  will  see  later,  testing  is  a  process  that  can  begin  very  early  in  the 
development  life  cycle  and  continues  throughout  the  process. 

This  is  a  narrow  view  of  testing.  When  we  empioy  a  broader  view  of  testing  we 
will  develop  a  better  product. 

(Learning  Label*  Today  we  are  going  to  ieam ...) 

Today,  using  the  KoFF  system,  we  are  going  to  Ieam  about  the  elements  of  a  test 
plan  and  how  the  early  development  of  a  test  plan  improves  requirements. 


CQNTEfiTS: 

1.  In  the  development  of  a  system,  we  can  divide  the  test  into  two  basic 
categories  -black  box  testing,  and  white  box  testing.  Black  box  testing 
examines  the  external  behavior  of  software,  primarily  testing  that  particular 
inputs  result  in  their  expected  outputs.  White  box  testing  examines  the 
internal  structure  and  behavior  of  software.  These  two  types  of  tests  are 
employed  at  several  testing  stages  of  software  development. 

2.  There  are  four  hierarchicaliy  structured  stages  of  testing,  that  most 
students  are  familiar  with: 

a.  unit:  examines  individual  procedure  as  a  stand  alone  components 

b.  module:  groups  together  units  so  that  they  can  be  tested  together 

c.  sub-system:  groups  together  collections  of  modules  and  test  both 
their  internal  correctness  and  their  interface  with  other  subsystems 
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d.  systems:  groups  together  sub-systems  and  test  the  entire  system. 
This  test  for  satisfaction  of  both  functional  and  non-functional 
requirements. 

There  is  a  different  type  of  testing,  called  acceptance  testing,  which  occurs 
when  a  software  product  is  delivered  to  a  customer.  The  function  of  this 
type  of  testing  is  to  prove  that  the  software  meets  the  needs  stated  in  the 
requirements  specification.  Because  this  type  of  testing  is  tied  to  the 
requirements,  a  preliminary  draft  can  be  developed  shortly  after  the 
requirements  are  finished.  The  specification  of  the  precise  system  functions 
to  be  tested  helps  to  clarify  the  requirements.  One  of  the  goals  in  the 
development  of  a  preliminary  test  plan  is  to  develop  a  requirements 
validation  test  matrix  which  related  every  requirement  to  a  specific  test  or 
set  of  tests-  called  a  test  suite. 

Test  Plan  contents 

Using  the  attached  instructors  notes,  work  through  the  Preliminary  test  plan. 
L90H1 

a.  Preliminary  Test  Plan-  There  are  many  forms  of  test  plans,  but  they 
all  have  similar  goals  in  common,  namely,  to  test  that  all 
requirements  are  satisfied  and  to  record  testing  information  in 
sufficient  detail  so  that  test  can  be  repeated  if  necessary.  To 
produce  similar  results  it  is  necessary  to  record  both  the  test  that  to 
be  done  and  the  order  in  which  they  are  done,  that  is  to  generate  a 
test  schedule. 

In  the  development  of  a  test  plan,  the  test  plan  designer  picks 
several  categories  of  function,  such  as  external  access,  to  organize 
the  test  around. 

L90H2 

b.  The  Test\Requirement  Traceability  Matrix  connects  each  requirement 
from  the  requirements  list  to  a  particular  type  of  test.  Some 
requirements  will  have  several  tests  associated  with  them  such  as 
requirement  2.  Later  in  the  design  stage,  other  types  of  tests  such 
as  inspections  and  reviews  will  be  included  in  the  test  plan.  This 
matrix  can  also  be  used  to  specify ,  under  demonstration,  those  tests 
which  wilt  be  part  of  acceptance  testing. 

L90H3 

c.  The  test  schedule  is  important  because  some  test  cannot  be 
conducted  until  other  stages  of  development  have  been  successfully 
completed  and  tested.  The  test  schedule  provides  information  to  the 
development  team  about  the  order  in  which  they  should  produce 
their  products. 
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L90H4 

d.  The  Status  R^x)ft  shows  the  progress  of  ail  testing  up  to  the  point 
of  the  report  within  the  categories  of  testing  :  access,  etc,  decided 
upon  by  the  test  manager. 

L90H5 

e.  Test  Results  Form  is  used  to  keep  track  of  the  results  of  individual 
tests.  Depending  on  the  results  of  the  tests  and  other  information 
gathered  during  testing,  the  requires  further  analysis  section  may  be 
filled  out.  Samples  of  how  these  forms  are  filled  out  are  included  as 
overheads,  upon  in  the  design  of  the  test  plan. 

L90H6 

f.  Tests  to  be  Performed  is  the  schedule  of  the  order  of  the  te&  g 
within  categories  and  tfie  dependencies  needed  to  be  satisfied  to 
preform  any  test. 

L90H7 

g.  Test  Procedure  Form  spells  out  the  low  level  structure  of  the  tests 
to  be  preformed  within  a  suite  of  tests. 

3.  Building  a  test  plan  provides  you  with  a  way  to  validate  requirements. 

a.  Example  -  in  the  KoFF  system,  by  designing  access  tests  it  was 
discovered  that  a  way  was  not  described  in  the  system  requirements 
for  the  owner  to  obtain  legal  access  to  the  system. 

b.  The  plan  also  helps  avoid  incomplete  testing.  Failure  to  complete  all 
stages  of  testing  can  have  significant  consequences.  Example  of 
incomplete  testing  •  Hubbeli  telescope  -  all  the  pieces  of  the  system 
were  tested  but  the  pieces  were  not  integrated  and  tested 
together.  This  resulted  in  an  expensive  system  failure. 


PROCEDURE: 

teaching  method  : 

(types  of  activities) 

This  lecture  contains  a  handout  -  KoFF  Video  Rental  System  Preliminary  Test 
Plan--  and  a  set  of  instructor  notes  explaining  the  plan.  The  students  need  to  have 
a  copy  of  the  plan  in  their  hands  to  follow  the  lecture  and  to  be  able  to  use  it  as 
a  model  for  the  development  of  their  own  plans. 

vocabulary  introduced: 
unit  testing 
module  testing 
subsystem  testing 
systems  testing 
test  plan 
system  failure 
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integration  testing 
requirements  validation  matrix 

INSTRUCTIONAL  MATERIALS: 


QVgfbMdg: 

L90H1 

Preliminary  test  plan  (KoFF  system) 

L90H2 

Test  requirementVtraceability  matrix 

L90H3 

Test  schedule 

L90H4 

Status  report 

L90H5 

Test  results  form 

L90H6 

Tests  to  be  performed 

L90H7 

Test  procedure  form 

haodouts: 

KoFF  test  plan 

RELATED  LEARNING  ACTIVITIES: 

(labs  and  in  ciass  exercises) 

Lab007-  Have  student  develop  classes  of  test  which  would  include  ail  of  the 
requirements  for  their  projects 

READING  ASSIGNMENTS: 

Sommervilie  Chapter  19,  22  (pp.  378-88,  425-441) 

Mynatt  Chapter  7  (pp.  276-315) 


RELATED  READINGS: 

Ghezzi  Chapter  6  (pp.  260-297) 
Pressman  Chapter  13  (pp.  631-659) 
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KoFF  Video  Rm^I  System 
PREUMINARY  TEST  PLAN^ 


1 .0  introduction 

The  test  plan  is  presented  in  sections  3.0  and  4.0  of  this  document.  Section  3.0 
describes  the  methodology  to  be  used  for  the  testing  process.  Section  4.0 
contains  test  procedures  to  be  executed.  These  procedures  are  derived  from  the 
requirements  specification  document  for  the  KoFF  Video  Rental  System.  Test  data 
developed  will  be  included  in  the  Appendix.  The  test  results  will  also  be  included 
in  the  Appendix  at  the  completion  of  the  testing. 

2.0  Referenced  Documents 

Electronic  Fund  Transfer  and  Charging  Standards.... 

KoFF  Client  Request  dated  June  11, 1993. 

KoFF  Data  Flow  Diagram  dated  June  14,  1993. 

KoFF  Preliminary  Design  documents  dated  June  15,1993. 

3.0  Test  Methodology 

The  following  paragraphs  will  describe  the  items  to  be  considered  in  the  planning 
of  the  tests  for  the  KoFF  Video  Rental  System. 

3.1  Test  Group  Involvement 

Considering  the  size  of  the  test  group  and  the  short  time  period  allocated 
for  the  test  activity,  the  test  group  will  participate  in  the  subsystem  test, 
perform  the  integration  test  and  then  demonstrate  the  acceptance  test.  The 
participation  in  subsystem  testing  is  limited  to  observing  the  designer's  test 
so  that  the  test  group  is  familiar  with  the  use  of  the  system. 

3.2  Requirements  Traceability 

The  methodology  for  showing  traceability  of  the  requirements  to  the  test  is 
be  that  the  requirements  are  identified  by  line  number  in  the  requirements 
list,  rather  than  by  paragraph  number  in  the  client  request.  The  method  for 
verifying  the  requirements  is  identified.  The  methods  used  are:  1) 
inspection  of  code,  hardware  ,  or  execution  results;  2)  test  and  analysis  of 
test  results;  and  3)  demonstration  of  the  system.  Similar  requirements  will 
be  grouped  in  the  test  procedures.^  The  test/requirements  traceability 
matrix  is  figure  3.2-1. 


'  This  plan  presumes  a  test  team  of  four  experienced  software  engineers. 
‘  Another  technique  is  to  group  requirements  by  major  system  functions. 
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TMt/RtquIrwiMnt  TraoMMIIty  Matrix 


Requirement  Test/Test  Method 


inspection 

Test/Anaiysis 

Demonstralion 

1 

D4 

2(1) 

A2 

2(2) 

D4 

2(3) 

D7 

2(4) 

DIO 

3 

D8 

4 

C11 

5 

C7 

6 

B1 

7 

A2 

8 

C3 

C3 

9 

C4 

C4 

10 

B7 

11(1) 

Cl 

Cl 

11(2) 

C6 

12(1) 

A2 

12(2) 

Cl 

12(3) 

C3 

12(4) 

C8 

12(5) 

Cl  2 

13 

14 

C13 

C13 

15 

D9 

D9 

16 

C2 

C2 

17 

D14 

18(1) 

C5 

C5 

18(2) 

C6 

19(1) 

A1 

19(2) 

A2 

19(3) 

Cl 

20 

B2 

21 

C15 

Cl 

22 

C16 

Figure  3.2-1 
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3^  TEST  SCHEDULE 


The  planning  schedule  for  the  tests  is  in  Figure  3.3*1 .  The  schedule  identifies  the 
plan  for  completing  the  plan,  developing  procedures,  test  data  sets,  test  softarare, 
and  test  execution. 


Test  Schedule 


Start  Date 

Complete  Date 

Activity 

June  10 

June  15 

Complete  Test  Plan 

June  28 

June  30 

Order  test  equipment 

June  30 

July  12 

Develop  test  procedures 

July  12 

July  15 

Generate  Test  Data 

Test  to  be  oerformed 

July  16 

July  18 

ACCESS  TO  THE  SYSTEM 
integration  order  1-5 

July  19 

July  23 

SELL  TAPES 

integration  order  6-9 

July  24 

July  27 

RENT  TAPES 

integration  order 

July  27 

July  27 

REGULAR  CHARGES 
integration  order 

July  27 

August  5 

LATE  CHARGES 

integration  order 

August  5 

August  7 

MANAGING  TAPES 
integration  order 

August  7 

August  10 

REPORTS 

integration  order 


Figure  3.3-1 
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3.4  Status  Raport  and  ProMam  Raport 


A  form  showing  the  means  for  tracking  and  reporting  the  testing  of  the  system  is 
included  in  Figure  3.4-1 .  A  problem  reporting  form  was  not  used. 

Function  Number's  of  Test  Procedures  % 

Procedures  Scheduied/Executed/Successfui  Success 

A.  Access 

B.  Inquiry/Selection 

C.  External  Responses 

D.  Add/DeleteAJpdate 

Figure  3.4-1 

3.5  Test  Procedures/  Results 

Figure  3.5-1  will  be  used  to  describe  test  procedures.  Figure  3.5-2  will  be  used  to 
describe  the  process  for  recording  test  results,  including  version  tested,  date  tested, 
and  results  will  be  described.  The  forms  to  be  used  are  in  Figure  3.5-1  and  3.5-2. 

TEST  PROCEDURE  FORM 

Function: 

Procedure: 

Requirements: 

Prerequisites: 

Test  Data  Required: 

Test  Steps: 

Analysis  Required: 

Figure  3.5-1 
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TmI  Prooedure: 

Dais  Test  Exscutad: 

Version  Number  Tested: 

Test  Results: 

Problems  Identified: 

Analysis  Results: 

Retests  Required: 

Figure  3.5*2 


The  test  procedures  are  developed  from  the  requirements  and  user  documentation  for 
integration  testing. 

The  first  procedures  will  be  for  a  test  of  the  integrated  system  functionality.  It  will  quickly 
answer  the  question,  "Is  it  worth  proceeding  to  perform  the  detail  tests?” 

Then  the  detailed  procedures  for  each  requirement,  or  group  of  requirements,  will  be 
developed.  These  procedures  will  take  into  consideration  testing  the  limits  as  well  as  the 
normal  input  data  cases.  Criteria  for  evaluation  of  results  will  be  included.  The  input  data 
needed  will  be  defined.  Any  processes  that  need  to  be  developed  to  prepare  or  evaluate 
the  data  will  be  de  ined. 

On  most  projects,  the  integration  and  acceptance  tests  would  not  be  included  on  the  same 
test  plan.  However,  it  appears  that  would  be  appropriate  on  this  pro^.  The  aooeptance 
tests  will  also  be  develop  from  the  requirements  document  and  also  use  to  the  maximum 
extent  possible  the  actual  data  available.  These  tests  will  have  the  objective  of  testing  the 
use  of  the  system  in  the  environment  of  the  user  community. 
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FuncliQiVProo0Ciur« 


Order  ^TmIs 


SuooeeiliJ 


PrereQiArili 

imegr^ion  Tests 
A.  Aoosss 


1. 

Customer  legai  card 

3 

D.4 

2. 

Customer  card  expired 

4 

D.4 

3. 

Customer  card  in^id 

D.4.  D9 

4. 

Owner  legal  access 

Inquiry/Selection 

1. 

Rental  Inquiry 

10 

A.I.  D.4.  D.5 

2. 

Sales  inquiry 

5 

A.1.  D.4.  D.10 

3. 

Tape  Rental  Report 

4. 

Sales  Report 

5. 

Customer  Rental  Report 

6. 

Tape  selection 

6,11 

7. 

Duration  selection 

12 

External  Responses 

1. 

Aooept/Retum  Member  Card 

2 

2. 

Capture  invalid  card 

3. 

Capture  Expired  Card 

4. 

Rental  Dispensing 

5. 

Sales  Dispensing 

8 

6. 

Tape  Charges 

7, 13 

7. 

Membership  charges 

8. 

Late  Charges 

9. 

Restocking  Charges 

10. 

Validate  charge  card 

11. 

Send  new  member  information 

12. 

Accept  input  tapes 

14 

13. 

Late  notice  phone  cali 

14. 

Send  memt^  removai  information 

15. 

Send  membership  information 

16. 

Send  rental  tracking  information 

Modify/Update/Add 

1. 

Change  video  tape  titles 

2. 

Change  video  tape  to  sale  item 

3. 

Change  Video  tape  prices 

4. 

Add  new  member 

1 

5. 

Change  movie  rental  information 

6. 

Change  customer  status  to  invalid 

7. 

Create  membership  number  and  pin 

8. 

Add  charge  card  information 

9. 

Invalidate  membership  card  number 

10. 

Change  Sales  inventory  information 

9 

Figure  3.5-1 
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TEST  PROCEDURE  FORM 


Function: 

Procedure: 

Requirements: 

Prerequisites: 

Test  Data  Required: 


A.1 

Customer  legal  access 
1 

Legal  membership 

Valid  membership  card 
number 


Test  Steps: 

a.  Insert  valid  card  into  system 

b.  Verify  rental  sales  option  screen  displayed 

c.  Select  quit 

d.  Verify  card  inserted  is  card  returned 

e.  Insert  a  card  which  is  not  an  RRR  membership 
card  * 

f.  Verify  display  of  "Not  an  RRR  card" 

g.  Verify  card  inserted  is  card  returned 

Analysis  Required: 

(note:  The  requirements  did  not  specify  what  to  do  if  a 
non-RRR  card  was  inserted.  The  test  designer  made 
a  design  decision  here.) 
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TEST  PROCEDURE  FORM 


Function:  A.2 
Procedure: 
Requirements: 
Prerequisites: 


Process  expired  card 
8 

Legal  membership 


Test  Data  Required:  Valid  membership  card 

number  with  expired  date 


Test  Steps: 

a.  Insert  valid,  but  expired  card  into  system 

b.  Verify  expired  card  screen  is  displayed 

c.  Verify  card  is  captured 

d.  Verify  membership  file  is  updated  * 

e.  Verify  that  the  "Welcome  to  KoFP  screen  is 
displayed  after  90  seconds. 

Analysis  Required: 

Check  timing  for  screens 


(note:  Requirements  did  not  say  how  to  track  expired 
cards.) 
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TEST  PROCEDURE  FORM 


Function: 

Procedure: 

Requirements: 

Prerequisites: 

Test  Data  Required: 


A.3 

Customer  iegai  access 
16 

Legai  membership,  invalidated 
card 

Invalid  membership  card 
number 


Test  Steps: 

a.  Insert  invalid  card  into  system 

b.  Verify  invalid  card  screen  is  displayed 

c.  Verify  card  is  captured 

d.  Verify  membership  file  is  updated  * 

e.  Verify  that  the  "Welcome  to  KoFF"  screen  is 
displayed  after  90  seconds. 

Analysis  Required: 

(note:  Requirements  did  not  say  how  to  track  expired 
cards.) 
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TEST  PROCEDURE  FORM 


Function: 

Procedure: 

Requirements: 

Prerequisites: 


B.1 

Process  Rental  Inquiry 
6 

Legal  membership 


Test  Data  Required:  Valid  membership  card 

number,  list  of  available  rental 
tapes 

Test  Steps: 

a.  Insert  valid  card 

b.  Verify  that  rental/sales  selection  screen  is 
displayed 

c.  Select  Rentals 

d.  Verify  that  rental  selection  screen  is  displayed 

e.  Verify  that  all  and  only  available  tapes  are 
displayed 

f.  Select  quit 

g.  verify  that  Thank  You  screen  is  displayed" 

h.  Insert  valid  card 

i.  Verify  that  rental/sales  selection  screen  is 
displayed 
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j.  Select  Rentals 

k.  Verify  that  rental  selection  screen  is  displayed 

l.  Verify  that  all  and  only  available  tapes  are 
displayed 

m.  Select  tape 

n.  Select  duration 

o.  Verify  that  customer's  account  is  charged 

p.  Verify  that  the  correct  tape  is  dispensed 

q.  Verify  that  available  tape  list  is  changed 

r.  Verify  that  membership  history  is  changed 

s.  Verify  that  'Thank  You"  screen  is  displayed  for 
30  seconds 

t.  Verify  that  the  "Welcome  to  KoFF"  screen  is 
dispiayed. 

Analysis  Required: 
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TEST  PROCEDURE  FORM 


Function:  B.1 


Procedure: 

Requirements: 

Prerequisites: 


Process  Rentai  inquiry 
(no  duration  seiected) 
6 

Legai  membership 


Test  Data  Required:  Valid  membership  card 

number,  iist  of  avaiiable  rentai 
tapes 


Test  Steps: 

a.  Insert  valid  card 

b.  Verify  that  rental/saies  seiection  screen  is 
dispiayed 

c.  Seiect  Rentals 

d.  Verify  that  rental  selection  screen  is  displayed 

e.  Verify  that  all  and  only  available  tapes  are 
displayed 

f.  Select  tape 

g.  Verify  that  within  45  seconds  "please  select 
duration  is  displayed" 

h.  Select  duration 

i.  Verify  that  customer’s  account  is  charged 
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j.  Verify  that  the  correct  tape  is  dispensed 

k.  Verify  that  available  tape  list  is  changed 

l.  Verify  that  membership  history  is  changed 

m.  Verify  that  'Thank  You"  screen  is  displayed  for 
30  seconds 

n.  Verify  that  the  "Welcome  to  KoFF"  screen  is 
displayed. 

Analysis  Required: 
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Prailmlnarv  Tett  Plan  Instructor  ItetM 


Numerous  test  plan  models  exit.  This  test  plan  model  is  designed  to  show  students  how  to 
trace  tests  to  specific  requirements.  It  sdso  can  be  used  to  show  students  how  the 
development  of  a  test  plan  can  act  as  a  verification  technique  for  requirements. 

The  plan  is  divided  into  four  major  sections.  The  introduction  outlines  the  structure  of  the 
plan  and  how  it  relates  to  a  particular  system.  The  second  section  on  referenced  documents 
should  mention  those  system  development  documents  which  were  used  to  build  the  plan. 
It  should  also  include  reference  to  documents  which  specify  special  constraints  for  the 
system.  Because  the  video  rental  system  automatically  charges  the  customer's  accounts, 
its  processing  must  conform  to  the  electronic  funds  transfer  act.  Knowledge  of  these 
staridards  is  needed  to  construct  adequate  tests  of  the  customer  charge  card  functions.  The 
third  section  specifies  the  test  methodology  and  the  fourth  section  lists  specific  test 
procedures.  In  this  plan  they  are  in  the  form  of  test  scenarios.  Other  techniques  would 
include  specific  code  or  the  results  of  automatic  test  generators.  They  would  also  include 
justification  for  the  choice  of  particular  test  cases  as  effective  test  cases.  This  is  a 
preliminary  plan  built  at  an  early  stage  of  the  life  cycle  so  low  level  code  details  are  not 
included.  At  this  stage  of  development,  the  presumption  is  that  detail  testing  will  be 
completed  separately  and  the  primary  function  of  this  plan  is  to  specify  integration  testing. 

The  order  of  the  major  sections  in  the  report  does  not  reflect  the  order  in  which  major 
decisions  are  made  about  the  test  plan.  Section  3  is  the  major  body  of  the  plan.  Section 
3.2  is  the  traceability  matrix  which  is  used  to  trace  failed  tests  to  particular  requirements. 
The  requirements  numbers  refer  to  the  KoFF  Adjusted  Requirements  List.  The  specific  tests 
or  test  methods  for  each  requirement  are  filled  in  from  the  test  procedures  listed  in  section 
4.0.  Section  3.3,  the  test  schedule,  is  also  dependent  on  section  4.0. 

The  first  step  in  the  development  of  this  test  plan  is  to  divide  the  system  into  its  major 
functions.  The  selection  of  these  functions  will  determine  all  the  other  elements  in  the  plan. 
In  the  development  of  this  plan,  the  major  function  we  selected  were:  system  access,  inquiry 
and  selection,  external  responses,  modify  the  data-update,  add,  delete.  These  are  listed 
under  major  functions  in  the  Test  Status  Report  (Figure  3.4-1).  The  remainder  of  that  report 
is  filled  out  as  the  system  is  developed.  These  are  the  categories  used  to  group  integration 
tests. 

The  second  step  is  to  subdivide  these  integration  test  categories  and  fill  the  tests  to  be 
performed  (Figure  3.6-1)  in  section  4.0.  The  integration  tests  are  listed  as  sub-functions. 
For  example,  the  sub-functions  under  access  indu^  attempts  to  access  the  system  with  all 
status  of  membership  card  and  attempts  to  access  the  system  by  Mr.  Richard.  The 
subfunctions  are  determined  by  referring  back  to  the  requirements.  A  general  testing 
strategy  is  determined,  which  is  listed  in  the  test  schedule  (Figure  3.3-1).  In  this  example 
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it  is:  test  access  to  the  system,  test  selling  tapes,  test  renting  tapes,  test  regular  charges, 
test  late  charges,  test  membership  management,  test  tape  management,  and  test  writing 
reports.  This  is  used  to  determine  the  order  of  testing.  Before  anyone  can  access  the 
system  they  must  be  a  member  so  the  first  function  to  test  is  D.4.  Then  A.1  customer  legal 
access  can  be  tested.  The  sequence  of  the  test  for  access  are  listed.  Many  integration 
tests  get  repeated  as  major  elements  in  the  testing  strategy  are  visited.  The  tape  selection 
B.6  tests  are  executed  in  the  rental  tapes  test  and  in  the  sales  tapes  tests.  This  is  a  good 
way  to  introduce  a  discussion  of  regression  testing.  After  the  order  of  integration  testing 
is  specified,  the  specific  integration  test  which  must  be  complete  in  order  to  begin  the  current 
integration  test  is  listed  under  "successful  prerequisite". 

At  least  one  problem  with  the  requirements  surfaces  when  students  try  to  list  the  successful 
prerequisites  for  integration  test  A.4  (Owner  legal  access)  in  section  4.0.  The  requirements 
are  quite  vague  about  the  way  Mr.  Richard  will  access  the  system.  If  it  is  unknown  whether 
he  wants  to  do  his  updates  at  the  Kiosk  by  using  a  special  access  card  or  do  his  updates 
remotely,  then  there  is  no  way  to  test  this  requirement.  Working  through  a  preliminary  test 
plan  shows  an  unstated  requirement. 

The  third  step  is  to  use  the  table  developed  in  section  4  under  Test  to  be  performed  and 
return  to  section  3  to  fill  in  the  test  matrix.  For  example,  the  first  requirement  in  the  revised 
requirement  list  is  to  accept  membership.  During  system  integration  this  is  tested  by  test 
set  D.4.  In  the  requirements  matrix  list  D.4  in  the  same  row  with  requirement  1 .  Follow  this 
procedure  when  filling  out  the  rest  of  the  matrix. 

The  last  element  is  to  give  complete  test  procedure  or  scenarios  using  Test  Procedure 
Forms.  A  complete  test  plan  will  have  a  test  procedure  form  tied  by  function  name  to  each 
integration  test.  The  scenario  for  "Legal  Access"  will  be  tied  to  integration  test  A.1.  The 
scenarios  represent  the  external  behavior  of  the  system  and  can  be  specified  at  this  stage 
of  development.  They  are  also  useful  requirements  clarification  tools  because  they  are  they 
can  be  understood  without  a  technical  background  and  they  sometimes  reveal  missing  or 
incomplete  requirements  (see  notes  to  Test  Procedure  Forms). 

The  procedures  related  to  particular  functions  are  filled'in  during  detailed  design.  The  test 
plan  again  functions  as  a  test  of  a  higher  life  cycle  stage.  When  the  test  are  actually 
performed,  the  test  results  form  is  filled  out  and  attached  to  the  test  procedure  form.  When 
all  testing  is  complete,  the  test  status  form  is  completed. 
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LECTURE  NUMBER:  010 

TOPICfS^  FOR  LECTURE: 

Ada  as  a  Design  Notation 


INSTRUCTIONAL  OBJECTIVEfS): 

1.  Make  students  aware  of  another  approach  to  designing  a  solution.  i.e., 
an  object-oriented  approach. 

2.  Introduce  Ada  package  specifications  as  part  of  a  design  notatk>n. 


SET-UP..  WARM-.UR: 

(How  to  invoive  learner:  recall,  review,  relate) 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

In  a  previous  lecture,  the  concept  of  design  was  introduced,  using  a 
functional  approach.  This  lecture  looks  at  a  more  object-oriented  approach 
to  design  where  the  system  is  decomposed  into  subsystems  and  the 
associated  information  and  actions/tasks  are  delineated. 

CONTENTS: 

L10OH1 

1 .  Discuss  criteria  for  "good  software  design" 

a.  A  design  should  be  readily  understandable. 

b.  A  design  should  be  readily  modifiable. 

c.  A  design  should  be  testable. 

d.  A  design  should  be  reusable. 

2.  Ada  as  a  design  tool 

L10OH2 

a.  Ada  notation  allows  us  to  perform  the  necessary  design  tasks 
of  high-level  or  architectural  design,  interface  design, 
component  specification,  algorithmic  or  low-level  design. 

L10OH3 

b.  Three  classes  of  subsystems  can  be  used  for  this  type  of 
decomposition:  user  utilities  e.g.,  directly  involving  the  user; 
resource  management  utilities  managing  the  data  stores;  and 
service  utilities.  Design  can  be  begun  by  decomposing  the 
system  into  subsystems  or  design  objects. 
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L10OH4 

c.  Working  from  the  analysis  documents  (the  requirements  list, 
context  diagram,  data  ftow  diagrams,  and  data  dictionary)  one 
can  make  a  preliminary  list  of  the  major  subsystems.  For 
example,  consider  the  dfd  for  the  KoFF  video  rental  system. 
The  following  subsystems  are  derived  from  the  KoFF 
subsystem  L50H3: 
member 
tape 
rental 

charge  card 

reports 

screens 

The  first  draft  of  the  Ada  specification  for  the  Member 
subsystem  was  presented  to  show  how  Ada  provides  a  design 
notation  that  is  understandable,  modifiable,  and  testable. 


d.  Consider  the  member  subsystem.  Identify  the  major 
processes  or  actions,  data  and  attributes  required  for  this 
system.  L10OH4  Using  this  list  one  can  develop  an  Ada 
package  specification  for  the  members  of  the  subsystem.  The 
details  of  the  member  subsystem  are  hidden  in  the  procedures 
and  functions. 

e.  Develop  similar  package  specHications  for  L10OH4, 
L1 0OH5.OH6.OH7,OH8,OH9 

This  Ada  specification  is  not  a  complete  one. 

PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 

subsystems 

user  utilities 

resource  management  utilities 
service  utilities 
Ada  specifications 


INSTRUCTIONAL  MATERIALS: 


overheads: 
L10OH1 
L10OH2 
L10OH3 
L50H4 
L50H5 


Software  Design 

Ada  as  a  Design  Tool  •  design  tasks 
Ada  as  a  Design  Tool  •  subsystems 
KoFF  system  •  context  diagram 
KoFF  system  •  level  0  diagram 
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L10OH4 

KoFF 

L10OH5 

KoFF 

L10OH6 

KoFF 

L10OH7 

KoFF 

L10OH8 

KoFF 

L10OH9 

KoFF 

handouts: 

Subsystems  -  Member 
Sub^rslems  es  ADA  speoificstions 
Sub^wtems  •  Tape 
Subsystems  -  Rental 
Sub^fstems  -  Charge  Card 
Sub^fstems  -  Reports,  Screens 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  008  -  Dmign  review  team  presentations  for  small  projects 
READING  ASSIGNMENTS: 

Sommetville  Appendix  A  pg  607-620 


RELATED  READINGS: 

Booch  Chapter  4  (pp.  28-43) 
Booch(2)  Chapter  2  (pp.  17-32) 
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Software  Design 


Criteria  for  "good  software  design" 

Design  should  be  readily  understandable 
Design  should  be  readily  modifiable 
Design  should  be  testable 
Design  should  be  reusable 
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"■  ■■ '  ■■  . . . . .  '■"  . . .  a 

Ada  as  a  Deaign  Tool 

Design  tasks 

High-level  or  architectural  design 
Interface  design 
Component  specification 
Algorithmic  or  low-level  design 
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Ada  as  a  Design  Tool 


Three  desses  of  subsystems 
User  utilities 

items  specified  in  the  requirements 

Resource  management  utilities 

responsible  for  some  resource  within 
the  system 

Service  utilities 

provides  services  to  other  subsystems 
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KoFF  SubsyttMiM 


Member 


information: 

name 

address 

telephone  number 
charge  card  info 
type 
number 
expiration  date 
member  card  number 
unique  personal  identification  number 
member  status 


actions  on  this  information: 
enroll  a  member 
invalidate  a  member 
modify  a  member's  information 
generate  membership  numbers 
check  membership  status 
retrieve  charge  card  number 


KoFF  SutaytlMns 
as  Ada  SpecNIeatfom 


package  MemberPkg  is 

type  Member  is  private; 

procedure  Enroll  (a_member :  Member); 

procedure  Invalidate 

(a_member :  Member); 

procedure  Modify  (a.member :  in  out 

Member); 

procedure  Generate  (for :  Member; 

card_number :  out  integer; 
id_number :  out  integer); 

procedure  Retrieve  (Charge_card_number : 

out  integer; 
for_a :  Member); 

function  Check_membership_status  (for_a ; 

Member)  return  Status_type; 

private 

type  Member  is  ... 
end  MemberPkg; 
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. .  '■  '  'luiaii  III  ,  W.III.I  mi  mmrntmiimwrm . .  ■  minpiiJJ  i  n 

KoFF  SubsytlMns 
Tape 

information: 
movie  name 
category 
movie  rating 
quantity 

transaction  type 
price 

info  per  tape 

bar  code  number 
availability  status 

actions  on  this  information: 
buy  a  tape 
update  inventory 
add  tape 
delete  tape 
modify  tape  title 
modify  tape  quantity 
modify  tape  transaction  type 
modify  tape  price 
change  avail^ility  status 
determine  available  rental  tapes 
determine  available  sales  ta^s 
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KoFF  Subsystems 


Rental 

(associates  MEMBER  and  TAPE) 


information: 

member  card  number 
bar  code  number 
check  out  date 
duration  iength 


actions  on  this  information: 
rent  a  tape 
return  a  tape 
process  5-day  late  tape 
process  1 0-day  late  tape 
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—  r,  •  •  -  -  — ■ •-»— ISTT 

KoFF  Subsystems 


Charge  Card 

confirm  customer  charge  card 

bill  membership  fee 

bill  rental  fee 

bill  sales  fee 

bill  1 0-day  late  fees 
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KoFF  Subsystems 


Reports 

generate 

generate 

generate 

generate 

generate 

generate 


new  customer  information  report 
membership  canceiiation  letter 
tape  rental  report 
customer  rental  report 
detailed  financial  report 
summary  financial  report 


Screens 

display  list  of  available  rental  tapes 

display  list  of  available  sales  tapes 

display  selection  menu 

display  membership  application  info 

get  application  information 

get  rental  information 

get  sales  information 
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LECTURE  NUMBER:  Oil 


TQPICfS^  FOR  LECTURE: 
Software  maintenance 


INSTRUCTIONAL  OBJECTIVEfS^: 

1 .  Know  the  relative  effort  and  costs  associated  with  software 
maintenance. 

2.  Distinguish  between  the  three  types  of  maintenance  (corrective, 
adaptive,  perfective). 

3.  View  performance  of  maintenance  as  a  rerun  of  the  software 
deveiopment  process,  involving  analysis,  design,  implementation, 
testing,  and  associated  documentation. 

4.  Understand  preventive  msyntenance  and  its  importance. 

5.  Appreciate  the  need  to  effectively  manage  and  control  change. 

SET  UP.  WARM-.UP: 

(How  involve  learner:  recall,  review,  relate) 

Refer  back  to  early  lectures  on  activities  involved  in  software  deveiopment. 

Use  overhead  LI  10H1  to  review  phases.  This  chart  depicts  the  percent 

of  effort  for  the  various  phases  in  developing  a  software  product.  Today 

weYe  going  to  talk  about  what  happens  after  the  product  has  been 

delivered  and  is  being  used. 

(Learning  Label*  Today  we  are  going  to  learn  ...) 

CQUIENTS: 

1 .  Discussion  -  What  is  maintenance,  in  genera!?  In  the  context  of 
hardware  (e.g.  automobiles)  this  generally  means  fixing  a  mistake. 
What  is  maintenance  in  the  context  of  software?  In  the  context  of 
software,  maintenance  is  much  broader  and  includes 
enhancements  and  additional  functionality  as  well  as  fixing 
mistakes.  [Note:  Pressman's  discussion  of  the  differences  between 
hardware  and  software  is  particularly  useful  here.  See  item  5 
below.]  Managing  maintenance  and  controlling  maintenance  costs 
are  significant  issues  in  software  engineering.  Software 
maintenance  encompasses  ail  of  the  activities  relevant  to  the 
software  product  that  occur  gftgc  it  has  been  delivered  and  installed. 


2.  Discussion  •  What  are  these  activities;  i.e.  what  are  the  different 
types  of  maintenance? 

a.  Corrective  •  fixing  defects  that  were  not  discovered  during 
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system  development. 

Examples  -  An  auto  manufacturer  recalling  vehicles;  a 
pacemaker  manufacturer  discovering  a  software  defect  after 
installation. 

b.  Perfective,  or  enhancement  -  adding  new  features  and 
functionality  to  system.  Note  that  Sommerviile  disagrees 
with  this  definition  when  he  says  perfective  maintenance 
improves  system  without  changing  its  functionality. 

Example  -  adding  a  Thesaurus  to  a  word  processor. 

c.  Adaptive  -  modification  in  order  to  respond  to  changes  in  the 
environment  in  which  system  is  operating. 

Examples  ■  change  in  income  tax  package  every  year  due  to 
changes  in  tax  laws;  adding  mouse  capability  to  a  program. 

d.  Characterize  perfective  and  adaptive  as  "good”  maintenance 
in  the  sense  that  this  activity  is  not  an  indicator  that  the 
software  is  bad;  perhaps  is  an  indicator  of  success,  that  it  is 
being  used  and  is  capable  of  being  modified.  Characterize 
corrective  as  "bad"  maintenance  in  the  sense  that  it  does 
indicate  a  defective  product. 


Maintenance  costs/effort. 

a.  Reiative  to  amount  of  effort  spent  on  development  (up  to 
time  product  is  deiivered  and  installed),  how  much  effort  is 
devoted  to  product  maintenance  (ever^hing  after  delivery 
and  installation)? 

L110H2 

Note  that  more  than  twice  as  much  effort  is  expended  to 
maintain  product  as  to  develop  it.  Therefore  anything  that 
can  iead  to  reducing  maintenance  costs  is  a  significant 
contribution. 

This  shouid  make  it  clear  why  maintainability  is  consistently 
listed  as  a  key  goal  in  software  development  (recall  it  is  one 
of  Sommerviile's  key  characteristics  of  well-engineered 
software;  it  is  a  key  consideration  during  design;  writing 
maintainabie  code  has  been  driiled  into  you  in  programming 
courses). 

b.  L1 1 0HS  reports  on  experiences  of  severai  iarge  companies 
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on  the  relative  costs  of  fixing  a  defect  at  various  stages  in 
the  development  process.  For  example  if  it  takes  $10  to 
detect  and  correct  a  fault  during  the  implementation  phase, 
that  same  fault  could  have  been  corrected  for  only  $2  if 
caught  during  specification.  Similarly,  it  will  cost  $200  if  not 
detected  until  after  the  system  is  delivered  and  in  use.  The 
key  point,  in  either  case,  is  that  the  earlier  errors  are 
detected  and  corrected,  the  less  cost  and  effort  is  involved. 

c.  LI  10H4  is  based  on  industry  data  where  identified  defects 
were  classified  as  requirement  definition  problems,  design 
problems,  etc.  Note  that  half  are  requirements  problems, 
and  75%  are  pre-implementation  errors. 

MORAL  -  It  pays  to  find  faults  early. 

d.  Discussion  question  -  Which  of  the  types  of  maintenance 
(corrective,  perfective,  adaptive)  do  you  think  is  most 
prevalent?  least  prevalent? 

LI  10H5.  Point  out  and  discuss  the  misperception  that  most 
maintenance  is  corrective. 


Approach  to  maintenance 

a.  Consider  a  maintenance  scenario.  A  software  product  is 
developed  using  a  sound  software  engineering  process,  is 
installed,  and  is  being  used  successfully  by  satisfied 
customers.  Based  on  use,  it  becomes  apparent  that  a  new 
capability  would  make  things  even  nicer.  The  customer 
requests  the  new  feature  (perfective/enhancement 
maintenance  request).  What  does  the  software  organization 
do?  Discuss  each  of  the  major  software  life  cycle  phases 
and  let  the  discussion  bring  out  that  maintenance  is  actually 
a  rerun  of  the  software  development  process  (requirements 
definition,  specification,  design,  implementation,  testing). 
L110H6 

b.  What  qualities  should  the  personnel  involved  in  maintenance 
possess?  Let  discussion  bring  out  that  they  need  analysis 
skills,  design  skills,  etc. 

Unfortunately  attitudes  towards  maintenance  tasks  are  often 
inconsistent  with  the  importance  of  maintenance.  It  seems  to 
be  undervalued;  some  organizations  may  talk  about  the 
importance  of  maintenance  but  not  put  their  money  where 
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their  mouth  is.  Some  manifestations  this  mistake  include  the 
following: 

i  The  role  of  maintenance  programmer  is  an  entry-level 
position  in  some  organizations.  You  put  the  new  kid 
there  and  their  first  promotion  is  out  of  maintenance. 

ii  Maintenance  is  not  sufficiently  emphasized  as  an 
important  criteria  for  acceptance  of  the  product. 

iii  Mention  specific  suggestions  by  Boehm  in 
Sommerville. 

c.  Introduce  preventive  maintenance  by  asking  if  they  can  think 
of  another  type  of  maintenance  term,  outside  software,  that 
they've  heard.  Extract  the  term  preventive  maintenance. 
What  does  the  term  mean  to  you  in  general;  what  sorts  of 
things  does  it  entail?  While  not  specifically  addressed  in 
most  textbooks.  Pressman  suggests  that  preventive 
maintenance  is  a  fourth  type  of  maintenance  activity.  It 
occurs  when  software  is  changed  to  improve  future 
maintainability  or  reliability,  or  to  provide  a  better  basis  for 
future  enhancements. 

Point  out  that  it  is  normally  not  difficult  for  software 
developers  to  anticipate/predict  requests  for  change  that  are 
likely  to  be  made  after  the  product  has  been  in  use  for  some 
period  of  time.  Discuss  this,  give  examples,  and  relate  this 
to  the  students  current  projects.  Stress  that  this  knowledge 
of  likely  areas  of  change  can  be  used  by  designers  and 
implementors  in  assuring  that  the  software  is  amenable  to 
change;  i.e.  is  maintainable. 

The  following  discussion  of  the  differences  between  hardware  and 
software  is  optional  but,  if  time  permits,  is  an  excellent  introduction 
to  the  topic  of  software  maintenance.  The  discussion  is  from 
Pressman,  pages  10-13. 

Begin  by  asking  "what  are  the  differences  between  hardware  and 
software".  Present  the  following  differences  given  by  Pressman. 

a.  Software  is  developed/engineered;  not  manufactured.  E.g. 
developing  hardware  involves  analysis,  design,  etc  but  it  is 
ultimately  manufactured.  What  is  the  manufacturing  phase 
for  software?  There  is  essentially  no  such  phase  for 
software.  Consider  automobile;  when  are  defects  introduced 
into  a  car?  Many  occur  during  manufacturing  phase  (e.g. 
"Monday  cars").  We  should  have  little  of  that  with  software 
since  it's  a  simple  replication  process.  The  key  point  here  is 
that  hardware  costs  are  concentrated  in  manufacturing  and 
that  is  not  true  for  software.  Therefore  a  whole  category  of 
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defects  that  are  frequent  in  hardware  should  not  even  exist 
in  software. 


b.  Software  doesnl  wear  out.  Sketch  the  failure  rate  curve. 

Pressman  Figure  1 .2,  for  hardware.  Discuss: 

i  Why  hioh  failure  rate  early?  hardware  exhibits  high 
failure  rates  early  (WHY?  -  design/mfg  defects) 

ii  Why  drop?  Defects  corrected  &  failure  rate  drops  to 
steady  state  for  some  period  of  time 

iii  Why  rise  aoain?  After  a  while  failure  rate  rises  as 
hardware  suffers  from  cumulative  effects  of  dust, 
vibration,  abuse,  environmental  factors;  i.i.  it  begins  to 
j^eaLQUi- 

Sketch  the  idealized  failure  rate  curve  for  software. 

Pressman  Figure  1 .3.  Since  software  is  not  susceptible  to 

those  things  that  cause  hardware  to  wear  out,  we  might 

expect  failure  rate  curve  for  SW  to  look  like  this. 

Show  the  actual  failure  rate  curve  for  software.  Pressman 

Figure  1 .4.  Discuss; 

i  High  failure  rate  early 

ii  As  changes  made  to  correct  defects,  new  defects  are 
introduced,  causing  "spike". 

iii  Before  curve  returns  to  steady  state,  more  changes 
made  &  another  spike. 

iv  Slowly,  minimum  failure  rate  rises  (look  at  actual  curve 
if  spikes  ignored);  the  SW  is  deteriorating  due  to 
change. 

6.  Configuration  management  -  introduce  term  as  transition  to  next 
lecture. 


Maintenance  involves  dealing  with  change.  Software  maintenance 
must  be  dealt  with  in  an  effective  controlled  manner,  consistent  with 
the  way  we  deal  with  software  development.  Otherwise  errors  will 
be  introduced  and  costs  will  unnecessarily  increase,  and 
maintenance  efforts  and  costs  would  continue  to  predominate.  The 
management  and  control  of  software  change  is  called  configuration 
management,  the  topic  of  the  next  lecture. 


PROCEPVRE: 

teaching  method  and  media: 


Generate  discussion  by  a  series  of  leading  questions.  This  topic  presents 
a  particularly  good  opportunity  for  discussion  since  analogies  with 
hardware  are  familiar  and  plentiful.  Student  responses  can  inevitably  lead 
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into  the  lecture  material  and  provide  an  appropriate  tMCkground  for 
preaenting  the  charts  on  maintenance  efforts  and  oosts. 

vocabulary  Introduced: 

maintenance 

corrective  maintenance 

perfective  maintenance  (enhancement) 

adaptive  maintenance 

failure  rate 

configuration  management 


INSTRUCTIONAL  MATERIALS: 
overheads: 

L1 1 0H1  Development  Effort 

L110H2  Relative  costs  of  phases  of  development 

L1 10H3  Relative  maintenance  cost  by  phase  of  deveiopment 
detected 


L1 1 0H4  Defects  classified  by  time  of  introduction 

L1 10H5  Maintenance  effort  distribution 

L1 1 0H6  input-Process-Oufout  of  maintenance 


handouts: 


RELATED  LEARNINQ  ACIIVLMS: 

(labs  and  exercises) 

Lab  009  -  Feedback  on  design  review  presentations 

Discussion  questions  (see  procedure  above). 

Exercise:  For  the  smaii  project  give  an  example  of  corrective,  adaptive, 

and  perfective  maintenance.  Make  a  iist  of  enhancement 
requests  that  might  be  anticipated  in  the  first  year  or  so  of 
operation.  Categorize  these  as  to  type  of  maintenance. 

REAPING  ASSIGNMENTS: 

Sommerviile  Chapter  28  (pp.  533*541) 

Mynatt  Chapter  8  (pp.  334-340) 


RELATED  READINGS: 

Booch  Chapter  23  (pp.  422-423) 
Booch(2)  Chapter  19  (p.  403) 
Qhezzi  Chapter  2  (pp.  25-30) 
Pressman  Chapter  1  (pp.  7-22) 
Schach  Chapter  1  (pp.  8-12) 
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Development  Effort  * 


Requirements 

10% 

Specification 

10% 

Design 

15% 

Code 

20% 

Module  Test 

25% 

Integration  Test 

20% 

*  does  not  include  maintenance,  which 
constitutes  the  largest  portion  of  the 
software  life  cycle 
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Approximate  Relative  Costs 
Phases  of  Software  Production  Process 

Source:  Schach,  Software  Engineering 


lliintMaiici67.0% 


12.0% 
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Software  Defects  Classified 
By  Time  of  Introduction 


Inadequate  or  incorrect 

requirements  definition 

50% 

Inadequate  or  incorrect  design 

15% 

Errors  in  detailed  design 

10% 

Coding  Errors 

20% 

Other 

5% 
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Maintenance  Effort  Distribution 
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Maintenance 


Input 


Software  specifications 
Preiiminary  design  document 
Detailed  design  document 
Test  plans  and  procedures 
Source  code 
Proposed  changes 


Process 


Incorporate  changes 
Retest  system 


Output 


New  program 

New  and/or  revised  documentation 
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LECTURE  NUMBER:012 


TOPICfS^  FOR  LECTURE: 

The  importance  of  controlling  diacipllnee  in  software  development 

Configuration  management 

Wdys  to  implement  configuration  management 


AL  QRIECHYECS): 


1.  Recognize  the  role  of  configuration  management  over  the  entire  life 
cycle. 

2.  Develop  and  evaluate  a  configuration  management  plan. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

L110H4 

We  have  just  talked  about  maintenance,  ^fei^tenance  »  change  to  software 
that  occurs  after  a  system  is  developed.  As  we  have  seen,  some  errors  are 
introduced  into  the  software  during  the  maintenance  process.  The 
development  of  software  is  a  continuous  process  of  change  and  affords 
developers  a  continuous  opportunity  to  introduce  errors  into  the  system. 
Some  would  consider  this  opportunity  for  the  introduction  of  error 
unacceptable.  We  cannot  alter  the  nature  of  the  devetopment  process,  but 
if  we  manage  and  control  the  process  of  change  we  can  restrict  the 
opportunities  for  introducing  error. 

(Learning  Label*  Today  we  are  going  to  learn ...) 

In  software  engineering,  the  principles  for  controlling  and  managing  change 
are  called  configuration  management.  Today  we  are  going  to  look  at  the 
principles  of  configuration  management  and  ways  in  which  configuration 
management  can  be  implemented. 


CONTENTS: 


1 .  Motivate  the  need  for  confiQuration  manaoementfCM)  by  discussing 
the  simultaneous  update  problem  and  version  control.  CM  is  not  just 
an  issue  about  software.  You  have  revised  your  small  project 
requirements  list  several  times.  Ask  the  students  what  changes  were 
made  to  the  requirements  list  and  whether  they  ail  were  certain  that 
ail  would  have  been  approved  by  the  customer?  Did  you  check  with 
the  customer? 


a.  Multiple  people  working  on  a  large  project  can  have  different 
understandings  of  what  the  system  is  supposed  to  do  or  may 
make  small  changes  which  do  not  work  well  wHh  other  parts  of 
the  system.  Using  the  test  plan  L90H6  remind  the  student 
that  the  test  planner  made  a  change  which  required  the  KoFF 
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system  to  track  expired  cards.  Was  this  information 
communicated  to  the  designers,  coders  or  even  to  the 
customer?  What  is  the  iikelihood  of  this  change  made  by  the 
test  pianner  ever  getting  implemented?  What  can  be  done  to 
assure  that  these  kinds  of  changes  are  acceptable  and  will  get 
implemented?  There  is  a  need  for  control  managemertt  and 
communication  of  change. 

b.  There  are  multiple  sources  and  reasons  for  change  requests. 
These  occur  throughout  the  development  process  as  welt  as 
after  system  development.  Talk  about  change  requests  as 
desired  improvements  in  the  system.  As  the  customer  better 
understands  the  system  he/she  sees  new  and  improved  ways 
that  the  system  could  be  developed.  Changes  also  come  from 
the  developers'  improved  understanding  of  the  requirements, 
and  changes  in  the  environment  while  a  system  is  being 
developed.  This  can  lead  to  chaos  unless  carefully  managed. 

c.  Sometimes  systems  are  developed  in  different  versions,  e.g., 
DOS  2.2  -  DOS  6.0.  Each  version  of  each  system  has  to  be 
tracked  and  maintained.  Versions  are  not  always  sequentially 
developed,  as  was  DOS  4.  DOS  5.  and  DOS  6.  Sometimes 
multiple  versions  of  the  same  system  are  developed 
concurrently  to  fit  on  different  hardware  platforms,  e.g.,  UNIX 
for  DEC  and  IBM  can  be  developed  at  the  same  time.  The 
requirements  for  these  systems  are  different,  and  one  must 
track  and  maintain  multiple  versions  of  the  "same"  product. 

d.  Talk  about  baselining  as  a  technique  for  limiting  or  controlling 
this  chaos.  How  is  baselining  done?  Be  sure  to  emphasize 
that  this  involves  formal  review  and  agreement  by  all  concerned 
parties.  Once  an  item  is  baselined  it  is  under  change  control 
and  can  only  be  changed  by  formal  change  control  procedures. 
What  is  it  that  gets  baselined.  Proposed  changes  to  baselines 
are  called  Change  ReouestsfCm. 


Methods  of  CM  require  a  plan,  a  well  defined  process,  and  a  manager 
to  carry  out  the  plan. 

a.  Ask  the  class  what  things  they  need  to  keep  constant  to 
develop  a  system.  List  these  on  the  board.  Discuss  them  as 
Configuration  Items  IC\).  Display  overhead  of  standard 
configuration  items  L120H1.  Work  through  each  item  talking 
about  those  items  which  are  new  to  them.  Be  sure  to 
emphasize  that  any  change  requires  approval  and 
communication  of  the  change  as  well  as  updating  the  affected 
documents.  Another  function  of  CM  is  to  maintain  consistency 
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between  the  documentation  of  a  system  and  the  system  itself. 

b.  CM  is  complex  and  requires  a  plan  to  be  sure  it  is  executed. 
Display  overhead  L120H2.  Go  over  the  contents  of  the  IEEE 
CM  Plan.  Briefly  go  over  the  management  issues,  such  as  how 
configuration  management  relates  to  other  organizations. 
Discuss  overhead  item  2.d  which  includes  naming  conventions 
for  components  and  how  CRs  will  get  processed.  Distribute 
handout  L12HD1  as  an  example  of  a  portion  of  a  student- 
produced  CM  plan. 

c.  To  maintain  control,  baselined  configurations  items  are 
sometimes  placed  in  a  special  electronic  library.  Permission  to 
change  or  modify  CIs  is  gained  through  a  CR  approval  process. 
CRs  are  generally  approved  by  groups  called  Configuration 
Control  Boards  fCCB^.  Discuss  some  standards  used  to 
decide  the  approval  of  CRs;  e.g,  functional  need,  cost  versus 
benefit  analysis,  impact  on  other  modules,  politics  (the 
president  of  the  company  "just  wants  it"). 

d.  There  are  several  virtues  of  CM  which  include  reducing  the 
number  of  errors  generated,  minimizing  the  use  of  storage, 
giving  visibility  to  system  development  progress  each  time  a 
new  Cl  is  baselined  and  reducing  the  time  and  effort  costs 
associated  with  uncontrolled  change. 


PROCEDURE: 

teaching  method  and  media: 

At  this  point  in  the  course  students  have  likely  experienced 
uncontrolled  changes  within  their  small  projects.  Some  of  these  have 
also  likely  caused  problems.  Their  own  "war  stories"  can  serve  to 
enhance  their  interest  and  appreciation  of  the  necessity  for 
configuration  management.  The  primary  teaching  technique  consists 
of  using  lecture  and  overheads  with  frequent  reference  to  problems 
they  have  encountered  in  their  small  project  teams. 

vocabulary  introduced: 

configuration  management  (CM) 
configuration  item  (Cl) 
baseline 

discrepancies  versus  changes 
configuration  control  board  (CCB) 
change  request  (CR) 
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iNSTRUCTIQNAl  MATERIALS: 

QVMhante: 

L120H1  Configuration  items 

L120H2  IEEE  Model  for  a  configuration  management  plan 

handouts: 

L12HD1  Student  configuratton  management  plan 

RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  010  -  Feedback  on  CI-5,  test  plans,  and  test  cases.Small  project 
team  preparation  for  team  acceptance  test  presentations 

RSAPINQ  ASSIGNMENTS: 

Sommerville  Chapter  29  (pp.  551-564) 

Mynatt  Chapter  8  (pp.  336-340) 

RELATEP  REAPtbIQS: 

Ghezzi  Chapter  7  (pp.  403-408) 

Pressman  Chapter  21  (pp.  693-708) 

Schach  Chapter  4  (pp.  87-93) 

James  Tomayko,  "Support  Materials  for  Software  Configuration 

Management."  Support  materisds,  SEI_SM_4_1 .0 

IEEE  Standa^  for  Software  Configuration  Management  Plans,  IEEE  Std  828- 

1983 
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Configuration  Kama 

Requirements  Documents 
Client  Request 
Requirements  List 
Analysis  Documents 
Revision  History 

Revision  requests  and  approvals 

Design  Documents 

Preliminary  Design  Documents 
Preliminary  Design  Review  Documents 
Detailed  Design  Documents 
Detailed  Design  Review  Documents 
Revision  History 

Revision  requests  and  approvals 

Code  Documents 

Source  code  modules 
Object  code  modules 
Compiler  used 
System  build  plan 

Other  Documents 
Test  Plan 
Test  Cases 
Test  Results 
User  Manual 
Referenced  Documents 
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IEEE  Moctol  for  a 

CONFIGURATION  MANAGEMENT  PLAN 

1 .  Introduction 

a.  Purpose 

b.  Scope 

c.  Definitions  and  acronyms 

d.  References 

2.  Management 

a.  Organization 

b.  Configuration  man^ement  responsibilities 

c.  Interface  control 

d.  Implementation  of  plan 

e.  Applicable  policies,  directives  and 
procedures 

3.  Configuration  management  activities 

a.  Configuration  identification 

b.  configuration  control 

c.  Configuration  status  accounting 

d.  Audits  and  reviews 

4.  Tools,  techniques,  and  methodologies 

5.  Supplies  Control 

6.  Records  collection  and  retention 
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Coffifigiinrtkm  Manapmut  Ptan 

r  PROJECT:  ThW  Eye  Project 

I  FILE  NAME:  CM.PLAN.OOC 

I  DOCUMENT  NAME:  Cortfiguretion  Management  Plan 


PURPOSE: 

This  document  describes  the  responsibiiitjes  of 
Configuration  Management. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price 

*  Created  Initial  revision  of  document. 


Computer  and  Information  Sciences 
Third  Eye  Project 

Configuration  Management  Plan 

Kellie  Price 
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1.  PURPOSE 


The  Configuration  Management  Plan  defines  the  Configuration  Management 
(CM)  policies  which  are  to  be  used  in  the  Third  Eye  Project.  It  also  defines 
the  responsibilities  of  the  project  configuration  manager. 


2.  MANAGEMENT 

2.1  CONFIGURATION  MANAGER  RESPONSIBILITIES 

The  first  responsibility  of  the  configuration  manager  is  to 
develop  and  implement  this  Configuration  Management  Plan. 

Throughout  the  project,  the  configuration  manager  will  report 
directly  to  the  customer.  It  is  the  configuration  manager's 
responsibility  to  ensure  that  the  project  is  implemented  in  a 
straight-forward  and  well-defined  manner  according  to  the 
customer's  specifications  and  standards  established  by 
Configuration  Management  for  this  project. 

2.2  ORGANIZATION 

This  project  will  be  divided  into  7  teams  as  follows: 

(Refer  to  CM_TEAMS.DOC  for  the  specific  team  assignments) 

NOTE:  All  of  the  documents  required  of  each  team  below 
are  listed  in  the  file  CM_DOCS.DOC. 

2.2.1  REQUIREMENTS  TEAM 

The  Requirements  Team  is  responsible  for 
communicating  with  the  customer  in  order  to  determine 
and  well-define  the  software  system  requirements.  The 
documents  required  of  the  Requirements  Team  are: 

*  Narrative  description  of  system 

*  List  of  requirements  (acceptance  criteria) 

*  Context  Diagram 

*  A  series  of  leveled  Data  Flow  Diagrams 

*  Data  Dictionary 

*  Process  Specifications 
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2.2.2  USER  MANUAL  TEAM 

The  User  Manual  team  is  responsible  for  producing  ail 
user  documentation  for  the  system.  The  documents 
required  of  the  User  Manual  Team  are: 

*  Preliminary  format  of  user  manual 

*  User  Manual 

2.2.3  TEST  PLAN  TEAM 

The  Test  Plan  team  is  responsible  for  designing 
subsystem  and  system  tests.  The  documents  required 
of  the  Test  Plan  Team  are: 

*  Test  plan 

2.2.4  PRELIMINARY  DESIGN  TEAM 

The  Preliminary  Design  team  is  responsible  for  creating 
a  preliminary  design  structure  of  the  system  based  on 
the  software  system  requirements.  The  documents 
required  of  the  Preliminary  Design  Team  are: 

*  An  Object  Model: 

*  Complete  object  diagram 

*  Class  dictionary 

*  Object'Requirements  traceability  matrix 

*  Ada  Specifications  for  each  object  class 

2.2.5  DETAILED  DESIGN  TEAM 

This  team  is  responsible  for  creating  algorithms  to 
implement  the  system  structure.  The  documents 
required  of  the  Detailed  Design  Team  are: 

*  Data  Structure  Design  using  a  data  structure 
dictionary 

*  Algorithm  Design  using  Nassi-Shneiderman  models 

*  An  object  attributes  and  object  operations  traceability 
matrix 

2.2.6  CODE  &  UNIT  TEST  TEAM 
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The  Code  &  Unit  Test  team  is  responsibie  for  producing 
source  code  for  the  algorithms  produoed  by  the  Detailed 
Design  Team,  integration  of  the  modules  to  produoe  a 

working  system.  The  documents  required  of  toe  Code 
&  Unit  Test  Team  are: 

*  Source  code 
2.2.7  TESTING  TEAM 

The  Testing  team  is  responsibie  for  implementing  the 
tests  in  the  test  plan  and  using  them  to  test  the  system. 
The  documents  required  of  the  Testing  Team  are: 

*  Test  data 

*  Documented  test  results 


CONFIGURATION  MANAGEMENT  ACTIVITIES 


3.1  C.M.  REQUIREMENTS  DOCUMENTS 

The  configuration  manager  has  provided  documentation  to 
assist  the  teams  in  meeting  the  C.M.  requirements.  This 
documentation  is  in  a  series  of  files  which  are  available  on  the 
project  file  server.  The  C.M.  requirements  defined  in  these  files 
are  as  follows: 


DESCRIPTION  FILENAME 


*  Documents  required  by  C.M. 

*  Document  header  info 

*  Document  naming  conventions 

*  Document  format  &  standards 

*  Change  request  form  format 

*  Configuration  Hern  request  procedure 

*  Confi^ration  item  access  procedure 

*  Configuration  item  change  process 

*  Configuration  item  baseline  process 


CM_DOCS.DOC 

CM_HEADR.DOC 

CM_NAMES.DOC 

CM_FORMT.DOC 

CM_CHREQ.DOC 

CM_CIREQ.DOC 

CM_ACESS.DOC 

CM_CHPRO.DOC 

CM_BASLN.DOC 


3.2  C.M.  CONTROL 

The  configuration  manager  will  provide  toe  teams  artd  team 
members  controlled  access  to  their  respective  configuration 
items.  In  order  to  have  aooess,  however,  the  teams  and/or 
team  members  must  provide  the  configuration  manager  with  a 
written 
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request  for  any  desired  configuration  Hems  as  defined  in  the  file 
CM_CIREQ.DOC. 


CONFIGURATION  MANAGEMENT  RECORDS 

All  BASELINED  Configuration  Items  and  documerrts  will  be  maintained  on  tfie 
project  file  server  in  a  directory  structure  as  defined  in  the  file 
CM_FILES.DOC. 


4.1  C.M.  FILES 

All  Configuration  Management  files  (including  the  requirements 
files  listed  in  section  3.1)  are  listed  below; 


DESCRIPTION 


FILENAME 


*  Configuration  item  access  procedure 

*  Configuration  item  baseline  process 

*  Configuration  item  change  process 

*  Change  request  form  format 

*  Configuration  item  request  procedure 

*  Original  customer  request 

*  Documents  required  by  C.M. 

*  C.M.  file  directory  structure 

*  Change  request  form 

*  Document  format  &  standards 

*  Document  header  info 

*  Document  naming  conventions 

*  Document  page  header 

*  Configuration  Management  Plan 

*  Software  Project  Management  Plan 

*  Project  team  organization 


CM_ACESS.DOC 

CM_BASLN.DOC 

CM_CHPRO.DOC 

CM_CHREQ.DOC 

CM_CIREQ.DOC 

CM_CRQST.DOC 

CM_DOCS.DOC 

CM_FILES.DOC 

CM_FORM.DOC 

CM_FORMT.DOC 

CM_HEADR.D<X 

CM_NAMES.DOC 

CM_PGHDR.DOC 

CM_PLAN.DOC 

CM_SPMP.DOC 

CM  TEAMS.DOC 
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LECTURE  NUMBER:  013 


TQPICfS^  FOR  LECTURE: 
Ada  and  maintenance 


INSTRUCTIONAL  QBJECTiVE(Si: 


1 .  Understand  technical  aspects  of  a  language  which  support 
maintainability. 

2.  Recognize  the  langus^  features  of  Ada  which  support  maintainability 
of  a  software  system. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 
(Learning  Label-  Today  we  are  going  to  learn  ...) 


CONTENTS: 

L130H1 

1.  Consider  and  discuss  three  technical  factors  that  affect  the 
maintainability  of  a  software  system:  completeness  and  consistency, 
understandability  of  progiam  and  its  documentation,  and  modifiability 
of  the  system. 

a.  Software  systems  in  industry  which  have  high  maintenance 
costs  are  systems  which  are  long  lived,  are  complex,  and  must 
adapt  to  changing  requirements  and  hanging  hardware.  The 
technical  factors  in  L130H1  are  needed  to  make  such  software 
systems  more  maintainable. 

b.  Completeness  and  consistency  of  system  documentation  are 
inde^ndent  of  ttie  implementation  language.  I  a  system  is 
complete  and  consistent  then  any  changes  made  to  the 
program  are  reflected  in  the  requirements  definition,  design 
documents,  test  plans,  etc.  T^  implementation  of  such 
completeness  and  consistency  is  dependent  on  project 
management. 

c.  Understandability  of  a  program  and  its  documentation  is 
important  so  that  changes  can  be  readily  made.  The 
understandability  of  the  program  is  a  language  dependent 
technical  factor. 

d.  Another  language  dependent  technical  factor  is  the  modifiabiiity 
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of  the  system.  A  system  is  modifiable  if  a  change  made  to  one 
part  of  the  system  affects  that  part  and  that  part  only.  The 
language,  therefore,  needs  to  provide  the  language  features 
which  allow  a  system  to  be  built  of  stand-alone  components 
which  do  not  interfere  with  other  system  components. 


L130H2 

2.  Discuss  specific  language  features  of  Ada  that  support  maintainability. 

a.  Named  association,  iliustrated  in  overhead  L130H3,  provides 
the  abiiity  to  assign  names  to  formal  parameters  and  to  use 
these  names  in  actual  parameter  association. 

b.  Overloading  provides  the  abiiity  to  define  multiple  meanings  to 
individual  operators  and  procedure/function  names. 
Overloading  allows  expressions  of  user-defined  types  to  be 
written  using  familiar  notation.  An  example  is  given  on 
overhead  L130H4. 

c.  Discuss  packages  and  how  they  promote  modifiability  in  a 
system  because  subsystems  can  be  built  which  act  as  stand¬ 
alone  components. 

d.  Discuss  the  separation  of  interface  specifications  and  bodies 
which  aiiows  the  detaiis  of  impiementation  to  be  abstracted 
away.  This  feature  promotes  understandability  because  only 
the  essentiai  interface  information  is  shown  and  the 
impiementation  detaiis  are  hidden  away  in  the  unit's  body. 
Discuss  separate  compiiation  of  the  spe^ications. 


PRCX)EDURE: 

teaching  method  and  media: 


vocabulary  introduced: 

named  association  of  parameters 

overloading 

separate  compiiation 

Ada  package  specification  and  body 

INSTRUCUQNAL  MATERIALS: 
overheads: 

L130H1  Maintenance 

L130H2  ,  Ada  and  Maintainability  -  features 

L130H3  Ada  and  Maintainability  -  example  of  named  association  of 
parameters 

L130H4  Ada  and  Maintainability  -  example  of  overloading 
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hanctouts: 


RELATED  LEARNING  ACTIViTIES: 

(labs  and  exercises) 

Lab  01 1  -  Presentation  of  customer  request  for  extended  project 

READING  ASSIGNMENTS: 

None 
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Maintenance 


Technical  factors  that  affect  the  maintainability 
of  a  software  system 


1.  Completeness  and  consistency  of 
system  documentation 

2.  Understandability  of  program  and  its 
documentation 

3.  Modifiability  of  the  system 
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■■  ^  »  "  -  '  -  '  '  Mill!  .  Iinui^  ■  Ml  UIIIIII  I.WIIII^  IIIP  I  j.ii  .  I.I  ly  I 

Ada  foatuias  which  support  maintainability 


Named  association  of  parameters 

Overloading 

Packages 

Separation  of  interface  specifications 
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ADA  AND  MAINTAINABILITY 


An  example  of  named  association  of  parameters 


procedure  definition: 

procedure  compute_speed 
(old_x_coord,  old_y_coord,  old_z_coord, 
new_x_coord,  new_y_coord,  new_z_coord:in  real; 

speed  :  out  real); 


procedure  invocation: 

compute_speed 
(13.459,  -18.634,  28.775, 

24.762,  -98.628,  45.350, 

value); 

compute_speed  (old_x_coord  =>  1 3.459, 

old_y_coord  =>  -1 8.634, 
old_z_coord  =>  28.775, 
new_x_coord  =>  24.762, 
new_y_coord  =>  -98.628, 
new_z_coord  =>  45.350, 
speed  =>  value); 
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AN  EXAMPLE  OF  OVERLOADING 


type  complex_number  is 
record 
■  ■  ■ 

end  record; 


procedure  multiply_compfex 

(c_1 ,  c_2  :  in  complex_number: 
c_3  :  out  complex_number); 


multiply_complex  (c_stream, 

cjsause, 

c_dir): 


function  (c_1 , 

c_2  :  in  complex_number) 
return  complex_number; 


c_dir  :=  c_stream  *  cjsause; 


LECTURE  NUMBER:  014 

TOPICfS^  FOR  LECTURE: 

Software  life  cycle  models 

INSTRUCTIONAL  OBJECTIYEIS): 

1 .  Understand  the  concept  of  a  software  life  cycle. 

2.  Understand  that  a  variety  of  life  cycle  models  exist. 

3.  Distinguish  between  several  life  cycle  models,  including  waterfall, 
prototyping,  and  spiral  models,  and  know  the  strengths  and 
weaknesses  of  each. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

Refer  back  to  the  introductory  lectures  on  the  various  activities  in  software 
development.  At  that  time  we  briefly  described  the  classic  iife  cycle  model 
and  discussed  some  of  its  strengths  and  weaknesses.  We're  going  to  review 
those  today,  with  a  iittie  more  detail,  and  then  discuss  some  other  life  cycle 
models  and  look  at  their  strengths  and  weaknesses. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 


We  will  be  looking  at  process  here,  as  distinguished  from  product.  An 
organization  that  can  devote  attention  to  process  as  well  as  product  has 
achieved  some  measure  of  maturity. 


CONTENTS: 


1 .  Concept  of  a  life  cycle  model  -  a  series  of  phases  through  which  the 
software  product  progresses  is  a  software  process  model,  or  a 
software  llfe-cvcie  model. 

a.  Fundamental  (generic)  steps  in  software  development. 

Review  the  fundamental  activities:  requirements  analysis, 
specification,  design,  implementation,  testing,  maintenance. 
Emphasize  that  in  general  there  are  ggt  the  sharp  boundaries 
between  the  different  iife  cycle  activities  that  are  implied  when 
we  differentiate  between  them  in  order  to  discuss  them. 

An  artificial  boundary  between  these  activities  is  indicated  by 
the  development  of  a  milestone  document. 

b.  Ad  hoc  methods  (e.g.  the  "bulld-and-fix  model"),  though  used 
in  places  and  even  referred  to  as  models,  are  not  really  life 
cyde  models  but  instead  demonstrate  the  absence  of  a  model. 


1 


Lecture  014 


We  are  considering  here  systematic  approaches  that  represent 
repeatable  processes. 


c.  Discussion  question:  Why  is  it  important  for  a  software 

development  organization  to  have  a  well  defined  process? 

i  To  define  activities  that  are  to  be  carried  out  and 
deliverables  and  milestones  associated  with  each 

ii  To  introduce  consistency  among  projects 

iii  To  provide  checkpoints  for  management  control  and  for 
go/no  go  dedsions 

iv  increasing  software  backlog  due  to  increased  demand 
for  software  services  -  Use  this  to  further  emphasize  the 
need  for  an  effective  process  for  software  development. 


Classic  life  cycle  model  (Waterfall) 

a.  Description  -  L140H1  -  Fig  1.7  Pressman 

This  is  a  systematic,  sequential  approach  similar  to  traditional 
engineering  cycles  and  note  that  there  is  feedback  between  life 
cycle  phases.  There  are  verification  activities  included  in  each 
phase. 

Consider  the  phases: 

i  System  engineering  -  Typically  the  software  is  part  of 
some  larger  system  and  this  phase  involves  establishing 
requirements  for  the  entire  system  and  then  allocating 
some  subset  of  this  to  software. 

Use  the  small  projects  as  an  example.  Identifying  the 
system  context  (scope)  and  interfaces  with  external 
entities.  This  "external"  view  was  necessary  before 
devoting  attention  to  the  software  system. 

ii  Software  requirements  analysis  >  This  involves  the 
extraction  and  clarification  of  requirements  for  the 
software  system. 

Requirements  and  specification  of  requirements  are 
documented  and  reviewed  with  customer  and  are 
baselined  as  a  software  configuration  item.  A 
preliminary  test  plan,  based  on  the  requirements  list,  is 
also  developed  and  baselined  here. 

iii  Design  -  The  design  is  documented  and  reviewed  with 
customer  and  becomes  part  of  the  software 
configuration. 

iv  Coding  and  component  testing  - 

The  results  of  component  coding  and  component  testing 
are  documented  and  checked  against  the  original  test 
plan  and  design.  Code,  test  data  &  test  results  become 
a  part  of  the  software  configuration. 


2 


Lecture  014 


V  Integration  and  system  testing 

After  successfui  test  results  are  achieved,  the  test  plans 
and  results  are  reviewed  with  customer  and  become 
part  of  the  software  configuration.  This  testing  is  called 
acceptance  testing. 

vi  Maintenance  -  reapplies  each  of  the  preceding  iife-cyde 
phases  to  an  existing  system. 

vii  The  waterteli  modei  is  the  oldest  and  most  widely  used 
software  life  cycle  model.  Schach  presents  a  variation 
on  the  waterfaii  modei  which  inciudes  verification  at 
every  phase.  If  verification  is  inciuded  as  an  integral 
part  of  each  phase  then  it  is  dear  that  this  is  not  an  ad 
hoc  modei.  L140H2  Here  a  phase  is  not  complete  until 
the  documentation  is  reviewed  and  approved  and  piaced 
under  configuration  control. 

b.  Strengths  of  waterfaii  model 

i  Disdplined  ■  requires  documentation  and  verification  at 
each  phase. 

ii  Documentation-driven. 

iii  Wideiy  used. 

iv  Far  better  than  ad  hoc  approach. 

c.  Weaknesses  of  waterfaii  model 

i  Even  with  feedback,  the  model  is  essentialiy  sequentiai 
and,  for  many  projects,  that  is  not  realistic,  it  is  often 
difficult  for  the  customer  to  state  all  requirements 
expiicitiy  at  the  start  of  a  project. 

ii  Documentation-driven  -  Whiie  listed  as  an  advantage,  it 

can  also  be  a  disadvantage.  The  documentation  is  often 
not  adequate  for  the  customer  to  understand  and  even 
though  he/she  is  signing  off  at  each  phase,  he/she  may 
not  really  understand  the  system  from  that 
documentation. 

iii  A  working  version  of  the  system  is  not  avaiiabie  until  the 
later  phases.  This  problem  is  addressed  in  the 
prototype  modei. 


Prototyping  modei  -  Introduce  this  by  discussing  how  the  weaknesses 
of  the  waterfaii  model  might  be  addressed. 

Prototyping  is  the  creation  of  a  functionally-  eouivaient  model  of  the 
system,  or  a  subset  of  the  system,  that  can  be  demonstrated  to  the 
customer.  This  demonstration  can  take  several  forms;  a  paper  model 
(e.g.,  showing  user  screens  and  reports),  an  existing  system  that 
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provides  similar  functionality  and/or  interface,  or  a  skeleton  version  of 

the  final  system.  Note  different  forms  the  model  can  take. 

L140H3 

a.  Prototyping  begins  with  requirements  gathering  (involving 
developers  and  customers)  followed  by  a  rapidly  developed 
design  and  constmction  of  a  prototype.  The  customer 
evaluation  of  this  working  version,  leads  to  a  clarification  of  the 
requirements. 

b.  Discuss  Brooks'  observations,  made  in  1975,  in  The  Mythical 
Man-Month.  Read  from  chapter  1 1  (Plan  to  Throw  One  Away), 
p116.  L140H4 

c.  Discuss  problems  associated  with  prototypes. 

i  Customer  sees  working  version  early  and  may  confuse 
the  prototype  and  the  final  system,  thus  expecting  a 
finished  product  in  an  unreasonable  amount  of  time. 
This  may  result  in  pressure  to  turn  the  prototype  into  the 
real  system  and,  in  turn,  would  result  in  an  inadequate 
(unmaintainable,  untested,  etc)  product. 

ii  Implementation  compromises  are  made  to  get  a  working 
prototype  early.  Developer,  for  a  variety  of  reasons, 
may  forget  these  compromises. 


Spiral  model  -  The  spiral  model  was  developed  by  Barry  Boehm  to 
incorporate  the  advantages  of  prototyping  into  the  waterfall  model. 

a.  Background  -  The  development  of  application  software  for  real 
customers  always  involves  elements  of  risk.  What  are  some 
risks? 

i  It  may  not  be  clear  that  some  requirements  are 
attainable  (response  times,  dependency  on  new 
technology,  new  theory,  schedule  requirements, 
necessary  personnel/expertise  not  available, 
requirements  not  testable,  etc) 

ii  Dependencies  on  other  systems  or  hardware  which  are 
beyond  the  developed  control  (relate  to  small  projects) 

Note  that  one  way  to  reduce  risk  would  be  to  build  a  prototype 
in  order  to  resolve  risks  early  in  the  project.  Review  the 
weaknesses  of  the  previously  discussed  models  (waterfall  and 
prototyping)  as  an  introduction  to  the  spiral  model.  This  gives 
an  historical  perspective  and  emphasizes  the  evolution  of 
process  modeis  for  large  software  systems. 
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The  intent  of  the  spiral  model  is  to  encompass  the  best 
features  of  the  waterfall  and  prototyping  approaches  and,  at  the 
same  time,  incorporate  risk  analysis.  In  the  spiral  model,  risks 
are  identifibd  and  an  attempt  is  made  to  resolve  them  through 
the  use  of  prototypes  and  other  means  the  students  how 
this  relates  to  the  projects  they  are  wo 


L140H5 

b.  Msyor  activities  represented  by  the  4  quadrants. 

I  Top>left  quadrant:  Planning  -  determination  of  objectives, 
alternatives,  constraints;  requirements 

ii  Top-right  quadrant:  Risk  analysis  -  analysis  of 
altematives  and  identification/resolution  of  risks 

iii  Bottom-right  quadrant:  Develop  this  portion  of  the 
system  following  the  most  appropriate  process  model. 

iv  Bottom-left  quadrant:  Customer  evaluation  -  assessment 
of  how  the  product  of  this  phase  relates  to  the  initial 
plan  and  the  product  of  the  previous  phase.  This  is 
followed  by  planning  the  next  iteration  of  the  spiral. 

c.  With  each  iteration  around  the  spiral,  progressively  more 
complete  versions  of  the  software  are  built.  During  the  first  trip 
of  the  spiral,  objectives  are  established,  alternatives  for 
achieving  those  objectives  and  constraints  are  identified. 
Based  on  the  risk  evaluation  a  development  model  is  chosen. 
(For  example,  if  risk  analysis  indicates  sufficient  uncertainty  in 
requirements,  prototyping  may  be  used).  Rnally  the  results  are 
evaluated  and  the  next  trip  around  the  spiral  planned.  Key 
elements  of  this  model  are  the  assessment  of  risk  at  regular 
intervals  and  the  initiation  of  actions  to  address/minimize  the 
risks.  Thus  high  risks  would  be  addressed  early.  Risk  analysis 
is  done  before  each  cycle  and  an  assessment  is  done  at  end 
of  each  cycle. 

d.  Strengths  of  spiral  model 

i  Emphasis  on  risk  identification,  assessment,  and 
resolution. 

ii  Considered  by  many  to  be  the  most  realistic  approach 
to  development  of  large  scale  software  systems. 

iii  Incorporates  advantages  of  waterfall  and  prototyping 
models. 

e.  Weaknesses  of  spiral  model 

i  Applicable  for  large-scale  systems  only. 

ii  Requires  risk  assessment  expertise. 
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5.  There  are  many  Hfe  cyde  models  possible:  weVe  looked  at  some 
representative  models  and  their  stiengths  and  weaknesses.  Ask  the 
students  what  factors  might  determine  the  particular  Ifs  cyde  model 
an  organization  chooses  for  a  project. 

a.  Stability  of  requirements 

b.  Problem  domain 

c.  Risk:  economic,  schedule,  feasibility,  safety,  etNcaiity 

d.  Organization  and  expertise  available 


PRQCEPURg: 

teaching  method  and  media: 

vocabulary  introduced: 

software  process  modei/life  cyde  model 

process  (vs  product) 

repeatable  process 

waterfall  model 

prototyping  model 

spiral  model 

risk,  risk  analysis 

INSTRUCTIONAL  MATERIALS: 
overheads: 

L140H1  Waterfall  model  (Pig.  1.7,  Pressman) 

L140H2  Waterfall  model  (Schach,  p.50) 

L140H3  Prototyping  (Pressman,  p.  28) 

L140H4  Quote  from  Brooks,  The  Mythical  Man-Month 
L140H5  The  spiral  model  (Sommerville,  p.  15) 

handouts: 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exerdses) 

Lab012  Project  Team  Organization 

BEAD1NG.ASSIGNMENTS: 

Sommerville  Chapter  1  (pp.  5<18) 
Mynatt  Chapter  1  (pp.  12-27) 
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RELATED  REAPINfiS: 

Ghezzi  Chapter  7  (pp.  357*383) 
Pressman  Chapter  1  (pp.  24-36) 
Schach  Chapter  3  (pp.  47*66) 
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Classic  Life  Cycle  (Pressman) 
Waterfall  Model 


Waterfall  Model  (Schach) 
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PsuedoCode  Example 

Policy  for  ordering  new  stock 
For  each  New_Stock_Request,  do  the  following; 

1 .  Search  for  an  Authorization_Form  with 
Reference_Number  equal  to  the 
Request_Number  on  the 
New_Stock_Request. 

2.  If  there  is  no  match 

Then  Discard  this  New_Stock_Request 
Else 

a.  Write  a  Purchase_Order  for 
Orderedjtem 

b.  From  Supplier_Catalog,  select  a 
Supplier  who  carries  the 
Orderedjtem 

c.  Copy  Supplier_Name  and 
Address  to  PurchasejOrder 

d.  Copy  Purchase_Order_Number  to 
New_Stock_Request 

e.  File  New_Stock_Request  with 
Authorization  Form 
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Process 

Data  Dlcfioiiaiy  Ponii 

Process  Nfaitie;  P&y  CM)ii  Dms 

Purpose:  Eveiy  four  weeks  produce  the  union 

deduction  register  end  consolidate 
employee  mk>n  deductions  to  output 
the  union  <^eck,  and  the  Accounting 
union  summary,  and  expanse  entry. 

Input  Data  Flows:  Bmpk>ym  Deduction 

Output  Data  ¥\ows:Umon  Expense  Entry,  Union 

$ummary,Union  Check,  Unhn  Deduct  Register 

Process  DescrlpSon; 

Sort  Employee  Unhn  Deductkm  by  Union  Number, 

Employee  Neme,  Week  Ending  Date 

For  each  Employee  Unhn  Deduction 
Output  Union  Dedurdhn  f^glster 
IF  Union  Number  changes 
Output  Unhn  Chedr 
Output  Unhn  Summary 


Shelly -Cashman,  Figure  4-35 
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Struotumd  Rsquireinente  SpecMcation 

Fuiidioit:  ChecK.caixljimildfly 

Descrl|i^n:  7hh  imj^  ensure  that  the  card 

InpiM  a  iiaer  fi^  been  ^ited  a 
subeofibifig  bemk,  %  In  date,  oentalns 
appropriate  account  Information,  and 
Induces  details  of  the  date  and  amount  of 
the  piBVIoys  cash  withdrawal. 

Inputs:  BankHdentl^r,  Account*number,  Expiry* 

date^  LasMran$action*date,  Last* 
transaction 

Source:  input  data  Is  read  from  the  card  magnetic 

stripe 

Oii^uts:  CardHitahJS  « (OK,  Invalid) 

Destination:  Auto*feiier,  The  card  status  1$  passed  to 

another  part  of  the  software. 

Requires:  6ank*list,  AcoounMormat,  Todays*date 

Pre-condition: 

Card  has  been  input  and  stripe  data  read 

Post-condition: 

Bank-ldenti^r  Is  in  Bank-list  and 
Account-number  matches  Account-format 
and  expiry-date  Todays-date  and  Last- 
Transactlon-date  <»  Todays-date  and 
Card-status  »  OK 
or  (If  any  of  these  tests  fall) 

Card-status  »kivalkl 


Sommerville,  Figure  5.1 
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Translation  of  Bank  Loan  Qualification 
Policy  into  a  Data  Flow  Diagram 


The  customer  is  approved  if  he  or  she  has  maintained  an 
average  monthiy  checking  balance  of  at  least  $1 ,000  for  each  of 
the  last  three  months  and  has  averaged  no  more  than  two 
overdrafts  per  month.  Customers  meeting  only  one  of  these 
conditions  but  maintaining  an  average  savings  account  balance 
of  at  least  $500  for  each  of  the  last  three  months  receive 
conditional  approval  with  an  automatic  loan  limit  of  $500. 
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Decision  Tabie  Covering  Poiicy 
For  Automatic  Loan  Quaiification 
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Decision  Tree  Expressing  A  Bank's  Poiicy 
Concerning  Loan  Quaiifications 


Decision  Tree  Showing  the  Fiow  of  Controi 


Elia8on,p.  390 
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Finite  State  Machine  Representation 
Of  Combination  Safe 


Schach,  Figure  7.8 
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Petri  Nets 
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Petri  Nets 


Schach,  Figure  7.16 
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Execution  of  a  Petri  Net 


IS 
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A  Wamler  Diagram 
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LECTURE  NUMBER:  Q2A 

TQeiC(S)  FQR  LECTURE: 
Transform  analysis 
Transaction  analysis 


INSTRUCTIONAL  OBJECTIVEfSk 


1 .  Understand  transform  analysis  and  its  application. 

2.  Understand  transaction  analysis  and  Its  application. 

3.  Recognize  when  transform  analysis  is  appropriate  and  when 
transaction  analysis  is  appropriate. 

4.  Understand  the  process  of  refining  first-draft  structure  charte  produced 
by  transform  analysis  or  transaction  analysis  considering  design 
criteria  such  as  coupling  and  cohesion. 

SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

In  your  first  project  you  had  to  develop  structure  charts,  without  using  any 

well-defined  method. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we're  going  to  look  at  two  methods  of  developing  stmcture  charts  from 

data  flow  diagrams. 

CQtilENTS: 


1 .  Transform  analysis  is  a  set  of  design  steps  that  can  be  applied  to  map 
a  data  flow  diagram  into  a  structure  chart.  Theoretically,  transform 
analysis  can  be  applied  to  any  system  but  it  is  more  appropriately 
applied  to  specific  t]^s  of  systems.  The  input  to  transform  analysis 
is  the  OFD  model;  the  output  is  a  first-draft  structure  chart. 

2.  The  first  step  in  transform  analysis  is  to  identify  the  central  transform 
in  a  DFD. 

a.  L240H1  ' 

For  many  systems  input  comes  into  the  system  from  the 
external  world  (keyed  in  by  user,  signals  from  a  sensor),  is 
transformed  by  some  internal  process(es),  and  results  are 
output  (printed  report,  graphics  display,  signal  to  external 
device).  The  overhead  represents  this  as  a  function  of  time  as 
the  system  performs  its  task.  Note  that  information  flows  from 
its  external  entry  Into  the  system  (the  afferent  streams),  imo 
some  internal  representation  where  the  essential  transformation 
takes  place,  and  then  flows  out  (the  efferent  streams)to  the 
external  world.  Tracing  the  Input,  at  some  point  the  input  data 
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ceases  to  be  input  and  becomes  internal  data.  i.e.  it  ceases 
being  raw  data  (through  verification,  editing,  filtering,  ... 
operations).  Similarly,  at  some  point  the  internal  data  is 
transformed  into  output  data.  The  key  to  transform  analysis  is 
identifying  the  part  of  the  system  where  the  "essential 
transform"  takes  place;  the  boundaries  at  which  raw  input  data 
has  been  transformed  into  essential  data,  and  at  which 
essential  data  becomes  output  data  but  still  has  to  be 
formatted,  refined,  etc  before  it  can  be  output  from  the  system. 

L240H2 

For  example,  consider  this  master  file  update  (briefly  review  or 
explain  a  traditional  master  file  update).  Where  does  the 
essential  transformation  occur?  Points  A  and  B  in  the 
overhead  are  the  beginning  of  the  afferent  streams;  at  these 
points  Field  and  Master  Record  enter  the  system.  Tracing 
each  of  these  inward,  it  is  at  points  E  and  F  where  these  input 
data  have  been  transformed  into  essential  data  (Valid 
Transaction  and  Valid  Master  Record,  respectively);  up  to  these 
points  the  raw  inputs  have  been  simply  validated  and  edited. 
Points  C  and  D  are  the  ends  of  the  efferent  streams;  at  these 
points  the  outputs  New  Master  Record  and  Applied  Transaction 
Report  Line,  exit  the  system.  Tracing  each  of  these  back  into 
the  system,  it  is  at  points  G,  H,  and  I  where  the  most  logical 
data  flows  first  appear  (Applied  Transaction,  Updated  Master 
Record,  and  Unmatched  Master  Record,  respectively);  following 
these  points  the  data  is  simply  being  formatted.  The  points  E, 
F,  G,  H,  and  I  mark  the  boundaries  of  the  central  transform.  If 
these  points  are  cx}nnected,  as  is  shown  by  the  dotted  line,  the 
transforms  inside  (5  and  6)  comprise  the  central  transform. 


L240H3 

This  system  inputs  a  file  name  and  outputs  the  number  of 

words  in  the  file.  Again,  identify  the  central  transform. 

Given  a  DFD,  the  central  transform  can  be  identified  as  follows: 

i  Trace  each  physical  input  to  the  point  at  which  the 
activities  performed  are  not  just  editing,  verifying,  or 
otherwise  cleansing  the  data,  but  are  truly  transforming 
it  some  way  (performing  calculations,  using  it  to  derive 
new  information,  etc).  Mark  those  points.  In  so  doing 
you  are  marking  the  data  flow  that  represents  the  input 
in  its  most  essential  form. 

ii  Trace  each  physical  output  backward  into  the  system  to 
the  point  where  the  activities  are  no  longer  simply 
formatting  the  data  for  output.  Mark  those  points.  In  so 
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doing  you  are  marking  the  data  flow  that  represents  the 
output  in  Its  most  essential  form, 
iii  Connect  the  points  marked  in  steps  i  and  ii  above.  The 
transform(s)  enclosed  represent  the  central  transform. 

The  central  transform  is  the  part  of  the  DFD  that 
contains  the  essential  functions  of  the  system  and  is 
independent  of  the  particular  implementation  of  the  input 
and  output.  The  identification  of  the  central  transform 
allows  the  designer  to  clearly  separate  internees  to  and 
from  the  system  from  the  essential  system  processing. 

3.  L240H4 

Once  the  central  transform  has  been  identified,  a  first-draft  structure 
chart  can  be  developed.  The  second  level  of  the  structure  chart 
consists  of  a  set  of  controller  modules,  one  for  each  of  the  afferent 
streams,  one  for  the  central  transform,  and  one  for  each  of  the 
efferent  streams. 

Consider  the  previous  example  of  the  system  to  count  the  number  of 
words  in  a  file  (L240H3).  The  first-draft  structure  chart  resulting  from 
transform  analysis  is  shown  L240H5.  Consider  the  cohesiveness  of 
these  modules.  Read-and-validate-file-name  and  Format-and-display- 
word-count  exhibit  communicational  cohesion.  Their  cohesion  levels 
can  be  improved  with  the  refinement  shown  in  L240H6.  Now,  all  of 
the  modules  are  functionally  cohesive.  This  refinement  represents  a 
good  preliminary  design. 

4.  L240H7 

Structure  charts  produced  through  transform  analysis  are  balanced 
hierarchies.  The  central  transform  is  isolated  from  the  input  and 
output  environment  by  placement  at  a  separate  level.  The  highest 
level  modules  are  isolated  from  low-level  I/O  details  since  they  see 
only  the  net  results  of  low-level  module  activity. 

5.  The  first-draft  structure  charts  produced  by  transform  analysis  must  be 
refined  with  consideration  given  to  design  criteria  such  as  cohesion, 
coupling,  fan-in,  fan-out,  and  modularity.  Other  good  examples  are 
given  in  Mynatt  in  section  4.3.  A  more  detailed  example  involving  the 
SafeHome  security  system  is  provided  in  Pressman,  pages  372-381. 

6.  While  transform  analysis  is  the  most  widely  applied  structured  design 
technique,  another  method,  transaction  analysis,  is  more  appropriate 
for  "transaction  centers"  within  a  system.  A  transaction  center  occurs 
when  a  single  transform  in  a  DFD  triggers  multiple  data  streams 
flowing  out  of  that  activity.  Transaction  centers  are  easily 
recognizable. 
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L240H8.  L240H9 

Consider  these  examples  as  well  as  Mynatt's  ATM  example  in  Figure 
4.12.  A  good  way  to  design  a  transaction  center  is  to  separate  it  into 
two  pieces;  one  to  analyze  the  transaction  (the  afferent  to  the 
transaction  center),  and  one  to  dispatch  the  transaction.  This 
separates  the  different  transactions  at  a  very  high  level  and 
discourages  the  tendency  to  share  common  elements. 

Discuss  the  types  of  structure  charts  that  result.  For  example, 
applying  transaction  analysis  to  the  DFD  in  L240H9  yields  the  first- 
draft  structure  chart  in  L24OH10.  Other  good  examples  are  given  in 
Mynatt  in  section  4.4.  A  more  detailed  example  involving  the 
SafeHome  security  system  is  provided  in  Pressman,  pages  382-389. 

7.  L240H11 

The  structure  charts  produced  by  transform  analysis  and  transaction 
analysis  must  be  refined  vmth  consideration  given  to  design  criteria 
such  as  cohesion,  coupling,  fan-in,  fan-out,  and  modularity.  They 
must  also  be  reviewed  to  verify  that  the  final  structure  chart  meets  the 
requirements  represented  by  the  DFDs.  Discuss  the  concordance 
example  in  Mynatt,  Section  4.3.4,  pages  162-167. 

PROCEDURE: 

teaching  method  and  media: 

vocabulary  introduced: 
transform  analysis 
afferent  streams 
efferent  streams 
central  transform 
factoring 

balanced  hierarchy 
transaction  analysis 
transaction  center 


INSTRUCTIONAL  MATERIALS: 

overheads: 

L240H1  Transform  flow 

L240H2  DFD  for  master  file  update 

L240H3  DFD  for  word  counter 

L240H4  First-level  factoring 

L240H5  First-level  structure  chart  of  word  counter 

L240H6  Refinement  of  word  counter  structure  chart 

L240H7  Balanced  hierarchies 

L240H8  Transaction  center 

L240H9  Ship  control  system 

L24OH10  Ship  control  system 

L240H1 1  Refinement  and  verification  of  structure  chart 
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handouts: 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

READING  ASSliaiNMEftHS: 

Sommerville  Chapter  2  (pp.  222-228) 
Mynatt  Chapter  4  (pp.  143*169) 

RELATED  READINGS: 

Ghezzi  Chapter  7  (pp.  394-402) 
Pressman  Chapter  1 1  (pp.  369-389) 
Schach  Chapter  10  (pp.  299-302) 
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Transform  Flow 


Unit 

(hfMhllit) 


Cmnllmrfm 

(TriMinlii) 


IftRit 
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DFD  For  Master  File  Update 
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DFD  For  Word  Counter 


Schach,  Figure  10.3 
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First  Levs!  Factoring 


Pressman,  Figure  11.9 
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First-L«vel  Structure  Chart 
of  Word  Counter 


0 - 


f- 


>ciitnliifiirai(iii 


Schach,  Figure  10.4 


Refinement  of  Word  Counter  Structure  Chart 


Schach,  Figure  10.5 
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Balanced  Hierarchies 


Structure  ch^^^^du^d^^through  transform 

The  central  transform  is  isolated  from  the 
input  and  output  environment  by 
placement  at  a  separate  level. 


The  highest  level  modules  are  isolated 
from  low-level  I/O  details  since  they  see 
only  the  net  results  of  low-level  module 
activity. 
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Cwitsr  Example 


Transaction 
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Ship  Control  System 


Transaction 

Tag 

Transaction 

Typo 

Transaction  Effect 

Turn 

Turn  ship. 

Turn  ship  from  present  angle  by  specified 
amount. 

Set 

Set  sNp 
course. 

Set  ship  to  absolute  course. 

Fire 

Fire  missile. 

Rre  missiie  in  specified  direction. 

Scuttie 

Self-destruct. 

Blow  up  ship  after  specified  time. 

Yourdon  Seminar  Notes 
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Ship  Control  System 
Structure  Chart 
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Reflnement  and  Varification  Of 
Structure  Chart 


The  structure  charts  produced  by  transform 
analysis  and  transaction  analysis  must  be 
refined  with  consideration  given  to  design 
criteria  inciuding  moduiarity,  cohesion, 
coupling,  fan-in,  and  fan-out. 

The  refined  structure  charts  must  also  be 
reviewed  to  verify  that  they  meet  the 
requirements. 
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LECIURE  NUMBER:  025 


TOPICfS^  FOR  LECTURE: 

Coupling  and  cohesion 

INSTRUCTIONAL  QBJECTIVEfS^: 

1 .  Understand  the  design  goals  for  cohesion. 

2.  Understand  and  distinguish  between  the  various  cohesion  levels. 

3.  Understand  the  design  goals  for  coupling. 

4.  Understand  and  distinguish  between  the  various  coupling  levels. 

5.  Evaluate  a  design  based  on  its  coupling  and  cohesion  characteristics. 

SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

In  earlier  lectures  we  have  discussed  coupling  and  cohesion  as  design 
criteria.  Recall  that  cohesion  is  a  measure  of  internal  strength  of  a 
component;  a  measure  of  how  well  the  internal  elements  of  a  component 
work  towards  the  goal  of  the  module.  Thus,  in  design  we  want  to  maximize 
cohesion;  to  design  highly  cohesive  components.  Recall  also  that  coupling 
is  a  measure  of  the  dependencies  between  components;  a  measure  of  the 
relationship  between  components.  Thus,  in  design  we  want  to  minimize 
coupling;  to  restrict  the  dependencies  between  components  to  those  that  are 
necessary. 

(Learning  Label-  Today  we  are  going  to  iearn  ...) 

Today  we  are  going  to  discuss  various  levels  of  coupling  and  cohesion  and 
how  to  evaluate  a  design  based  on  its  coupiing  and  cohesion. 

CONTENTS: 

L250H1 

1 .  One  attribute  of  a  design  is  its  modularity.  What  do  we  mean  by  that; 
exactly  what  is  a  module?  Consider  a  moduie  as  a  black  box  with 
four  basic  attributes. 

i  It  interface.  Input  and  output  -  what  it  gets  from  its  invoker 
(input)  and  what  it  returns  (output) 

ii  Function  -  what  it  does  to  its  input  to  produce  its  output 

iii  Mechanics  -  procedural  logic  to  performs  its  function 

iv  Internai  data  •  its  own  private  data  or  work-space  or  data 
structure 

Items  i  and  ii  comprise  the  external  view  of  a  module.  Items  iii  and  iv 
comprise  the  internal  >dew.  Preliminary  design  is  concerned  with  the 
external  view.  Functionai  independence  is  a  key  to  good  design,  and 
thus,  to  software  quality.  Why?  Because  the  design  will  be 
maintainable,  testable,  and  have  a  higher  potential  for  reuse.  Ideally, 
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this  is  achieved  by  developing  modules  that  are  single-minded  (do  a 
single,  dearly-defined  function),  avoid  interactions  with  other  modules 
except  where  necessary.  In  those  cases,  where  interaction  is 
necessary,  keeps  it  as  simple  as  possible. 


2.  Cohesion  is  a  design  criteria;  a  measure  by  which  we  can  evaluate  a 
design.  Cohesion  is  a  measure  of  a  module's  internal  strength;  a 
measure  of  how  well  a  module's  internal  elements  are  related  to  each 
other.  Ideally,  a  cohesive  module  does  just  one  thing.  A  function  with 
no  side-effects  is  an  excellent  example  of  a  cohesive  module.  A 
number  of  levels  of  cohesion  have  been  identified.  L250H2  As  the 
overhead  indicates,  these  levels  represent  a  spectrum.  The  scale  in 
gst  linear.  The  low  end  (coinddental)  is  very  bad,  and  should  always 
be  avoided,whereas  the  middle  levels,  which  are  not  that  far  away 
from  the  high  end  (functional),  are  sometimes  unavoidable.  L250H3 
The  lower  levels  of  cohesion  lead  to  a  maintenance  problem. 

a.  Coincidental  cohesion  -  there  is  little  or  no  meaningful 
relationship  between  the  elements  of  the  module.  Such 
modules  perform  multiple,  unrelated  tasks.  This  is  the  worst 
type  of  coupling  and  also  easiest  to  avoid.  The  problems  are 
obvious:  difficult  to  maintain  and  offer  little  opportunity  for 
reuse. 

b.  Logical  cohesion  -  module  performs  a  series  of  related  actions, 
one  of  which  is  selected  by  the  calling  module.  This  occurs 
when  elements  are  grouped  into  a  class  of  related  functions 
and  placed  into  a  single  module.  Examples  are  a  module  that 
handles  all  output,  general  purpose  error  handling,  and 
modules  that  perform  all  input.  Problems  with  logical  cohesion 
include  a  complex  internee  ,  hard  to  understand  module,  and 
code  for  different  actions  may  intertwine,  causing  maintenance 
problems.  For  example  in  L250H4,  the  addition  or  deletion  of 
hardware  would  cause  significant  modification  in  the  module. 

c.  Temporal  cohesion  -  module  performs  a  series  of  actions  that 
are  related  by  time,  actions  that  must  be  done  at  the  same  time 
(or  in  the  same  time  span).  Typical  examples  are  initialization 
modules  that  do  a  variety  of  things  (like  open  files,  clear 
counters,  initialize  flags);  or  "wrap-up"  modules  that  ctose  files, 
compute  final  totals  and  averages,  and  print  final  report.  CS1 
instructors  tend  to  emphasize  these  types  of  modules;  (e.g., 
initialize  all  conditions  and  totals,  other  housekeeping  chores). 
This  leads  to  tight  coupling. 

d.  Procedural  cohesion  -  module  performs  a  series  of  actions  that 
must  be  done  in  a  particular  order;  the  elements  are  related 
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more  to  program  procedure  than  to  program  function.  They 
often  tend  to  cut  across  functional  boundaries.  Not  always 
bad,  in  fact  from  this  point  upward  on  the  cohesion  spectrum, 
the  levels  of  cohesion  are  significantly  more  maintainable  than 
the  lower  levels.  An  example  of  procedural  cohesion  is  a 
module  that  reads  a  part  number  from  a  data  store  and 
updates  a  repair  record  in  a  maintenance  data  store.  Although 
procedurally  cohesive  modules  are  more  maintainable  than 
those  with  lower  levels  of  cohesion,  they  are  not  easily 
reusable. 

e.  Communicational  cohesion  and  sequential  cohesion  •  perform 
a  series  of  actions  related  by  a  sequence  of  steps;  an 
assembly-line  order.  If  all  the  actions  are  preformed  on  the 
same  data  structure  than  the  cohesion  is  communicational. 

Examples:  Determine  length  and  slope  of  line 

Read  record  and  eliminate  duplicates. 

Format  and  verify  voter  profile. 

Tasks  at  this  level  are  directly  related  to  the  problem  so 
maintainability  is  not  bad  but,  again,  decreases  potential  for 
reuse 

f.  Functional  cohesion  -  module  performs  a  single  task  and  each 
part  of  the  modules  is  necessary  to  perform  that  task. 

Examples:  Calculate  sales  commission 
Get  temperature  of  furnace 
Determine  students  GPA 

Note:  the  cohesiveness  of  many  of  the  earlier  examples  could 
be  improved  to  functional  by  breaking  them  into  multiple 
modules. 

Discuss  why  such  modules  are  easier  to  maintain 
Fault  isolation 
Easy  to  understand 

Less  chance  of  impacting  other  modules 
Easier  to  extend/repiace 
Better  chance  of  reuse 

Example:  Discuss  this  example  with  the  students.  L250H5 

g.  Informational  cohesion  -  This  is  an  additional  level  of  cohesion 
identified  by  Schach.  A  component  exhibits  informational 
cohesion  if  it  has  a  number  of  elements,  each  preforming  an 
action  on  the  same  data  structure,  and,  each  element  has  its 
own  entry  point. 
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Example:  L2SOH6  The  difference  between  this  and  logical 
cohesion  is  that  here  the  various  elements,  each  performing 
one  action,  are  independent  whereas  in  togicai  cohesion  the 
elements  are  intertwined.  This  lies  just  below  functional  on  the 
cohesion  scale. 

Summary  on  cohesion:  If  a  module  exhibits  more  than  one 
type  of  cohesion.  K  is  labeled  as  the  worst  of  those  types.  One 
should  develop  modules  that  have  a  single  problem-related 
function.  This  increases  independence,  clarity,  maintainability, 
and  reuse.  A  functionally  cohesive  module  can  be  accurately 
described  with  a  simple  sentence  containing  an  imperative  verb 
and  a  specific  singular  object.  Otherwise,  the  module  is  less 
than  functionally  cohesive.  L250H7,  L250H8  is  Meitor  Page- 
Jones'  organization  of  cohesion  and  its  trade-offs.  The  Y-axis 
represents  the  lifetime  cost  per  arTK>unt  of  functionality  provided 
and  the  X-axis  is  the  levels  of  cohesion.  Page-Jones  has  an 
excellent  discussion  of  these  trade-offs. 


Coupling  is  another  design  criteria;  a  measure  by  which  we  can 
evaluate  a  design.  Coupling  is: 

i  a  measure  of  the  dependence  between  two  modules 

ii  a  measure  of  interconnection  between  module 

ii  it  is  the  degree  of  interaction  between  two  modules. 

A  major  design  goal  is  to  minimize  dependencies  by;  developing 
loosely  coupled  modules.  Low  coupling  is  achieved  by  eliminating 
unnecessary  relationships  and  minimizing  the  number  and  "tightness" 
of  necessary  relationships.  A  number  of  levels  of  coupBng  have  been 
identified.  L250H9  spectrum  (p  336  Pressman).  As  the  overhead 
indicates,  these  levels  represent  a  spectrum.  As  with  the  cohesion 
spectrum,  the  scale  in  ogi  linear. 

L25OH10 

a.  Content  coupling  -  One  module  refers  to  the  internals  of 
another. 

Examples  (Assume  modules  A  and  B)  include: 

A  modifies  a  statement  of  B 
A  refers  to  local  data  of  B 
A  branches  inside  B 

These  are  c  easy  to  avoid,  inexcusable,  violations  of  anybody's 
programming  standards. 

0.  Common  coupling  -  Two  modules  have  access  to  same  global 
data  area. 
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c.  Control  coupling  -  One  module  passes  an  element  of  control  to 
another  module,  i.e.  exolldtlv  controls  its  logic.  Examples  of 
control  are  function  codes,  flags,  and  switches,  if  a  table 
lookup  routine  passes  back  a  flag  "entry  not  found"  there  is  no 
control  coupling.  If  however,  it  passes  back  "entry  not  found, 
add  this  item"  then  the  table  look  up  module  that  called  it  is 
control  coupled.  In  the  latter  case  the  boss  is  being  told  what 
to  do;  in  the  former  case  the  boss  is  being  apprised  of  the 
situation. 

d.  Stamp  coupling  -  One  module  passes  a  data  structure  as  a 
parameter  but  the  called  module  operates  on  some  but  not  all 
of  the  individual  components  of  the  data  structure.  Stamp 
coupling  exposes  modules  to  more  data  than  they  need.  This 
exposes  the  data  structure  to  corruption. 

e.  Data  coupling  occurs  when  parameters  are  passed  or  a  data 
structure,  all  of  whose  elements  are  needed  bv  the  called 
module.  The  fact  that  a  data  structure  is  passed  does  not  entail 
stamp  coupling. 

f.  Two  modules  may  exhibit  more  than  one  type  of  coupling.  In 
such  cases,  the  degree  of  coupling  is  considered  as  the  worst 
of  the  types  exhibited. 

L2SOH11  is  an  example  of  different  couplings.  Discuss  this 
with  the  class  and  go  over  the  answers  L250H12. 

g.  Considerations  in  designing  modules: 

i  imagine  modules  as  library  functions;  how  would  they  be 
easiest  to  understand;  how  might  they  be  reusable? 

ii  Assume  each  module  will  be  implemented  by  a  different 
programmer.  How  independently  can  the  programmers 
work?  Are  there  any  assumptions,  constraints,  or 
conventions  that  one  module  need  be  aware  of  and  how 
likely  are  they  to  change?  Can  the  change  be  isolated 
to  a  single  module? 

If  two  modules  are  highly  coupled,  there  is  a  higher  probability 
that  a  change  in  one  will  require  a  change  to  the  other. 
L250H13  is  Page-Jones'  organization  of  coupling  and  its 
tradeoffs. 


EBQCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 


5 


Lecture  025 


cohesion 

coindclental  cohesion 
logical  cohesion 
teniporal  cohesion 
procedural  cohesion 
oommunicational  cohesion 
sequential  cohesion 
functional  cohesion 
informationai  cohesion 
coupling 
content  coupling 
common  coupling 
control  coupling 
stamp  coupling 
data  coupling 


INSTRUCTIONAL  MATERIALS: 
g^filDfiads: 

L250H1  Attributes  of  a  module 

L250H2  Cohesion  Spectrum  (Pressman,  p  334) 

L250H3  Cohesion  level  definitions 

L250H4  Logical  cohesion  example  (Schach) 

L250H5  Structure  chart  showing  cohesion  of  each  module  (Schach,  Fig 


9.7) 

L250H6  Module  with  informational  cohesion  (Schach,  Fig  9.6) 

L250H7  Guidelines  for  determining  cohesion  level  (Pressman,  p.  335) 
L250H8  Costs  as  function  of  cohesion  level  (Page-Jones,  Table  6.2,  Fig 
6.15) 

L250H9  Cou^ing  spectrum  (Pressman,  p  336) 

L25OH10  Coupling  ievel  definitions 

L250H11  Coupling  example  (Schach,  Fig  9.11  -  9.12) 

L250H12  Coupling  example  (Schach,  Fig  9.13) 

L250H13  Qualities  of  coupling  levels  (Page-Jones,  Table  5.2) 


RELATED  LEARNING  ACTIYIIISS: 

(labs  and  exercises) 


REAPING  ASSI6NMENT5: 

Mynatt  Chapter  4  (pp.  144-150) 

RELATED  READINGS: 

Ghezzi  Chapter  3  (pp.  49-52) 
Pressman  Chapter  10  (pp.  332-337) 
Schach  Chapter  9  (pp.  235-253) 
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Melir  Page^ones.  Practical  Guida  to  Stnjetuwd  Daaion.  2nd  ad.  1988, 
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Attributes  of  a  Module 


Interface  - 

Its  input  and  output 

Function  - 

What  it  does  to  its  input  to 

transform  it  into  output 

Mechanics  - 

Internal  logic  (code) 

Internal  data 
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CohMion 


A  iMim  if  fti  rMN  teeM  ilrii|i 
•f  a  mMi 
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COHESION  LEVELS 


Coincidental  -  Little  or  no  meaningful 

relationship  between  elements  of 
the  module 

Logical  -  Performs  series  of  logically 

related  functions  in  module; 

functions  falling  into  some  general 
category 

Temporal  -  Performs  series  of  actions  related 

by  time  (that  must  all  be  done  at 
same  time  or  in  same  time  span) 

Procedural  -  Performs  series  of  actions  that 

must  be  done  in  a  particular 
order;  elements  related  more  to 
procedure  than  to  function 

Communicational 

Sequential-  Performs  series  of  actions  related 

by  sequence  (output  of  step  is 
input  to  next)  or  all  of  the  actions 
performed  on  the  same  data 

Functional  -  Performs  a  single  task  and  each 

element  of  module  is  necessary 
to  perform  that  task 
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Example  of  Logical  Cohesion 


Module  Performing  All  Input  and  Output 

_ 1  ■  Code  for  all  input  and  output 

_ 2.  Code  for  input  only _ 

_ 3.  Code  for  output  only _ 

_ 4.  Code  for  disk  and  tape  I/O 

_ 5.  Code  for  disk  I/O _ 

_ 6.  Code  for  tape  I/O _ 

_ 7.  Code  for  disk  input _ 

_ 8.  Code  for  disk  output _ 

_ 9.  Code  for  tape  input _ 

1 0.  Code  for  tape  output 


ource  :  scnach,  Pig  9. 
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Module  with  Informational  Cohesion 


Guidelines  for  Determining  Cohesion  Level 

A  useful  technique  in  determining  whether  a 
module  is  functionally  bound  is  writing  a  sentence 
describing  the  function  (purpose)  of  the  moduie, 
and  then  examining  the  sentence.  The  following 
tests  can  be  made: 

1.  If  the  sentence  has  to  be  a  compound 
sentence,  contains  a  comma,  or  contains  more 
than  one  verb,  the  module  is  probabiy  performing 
more  than  one  function;  therefore,  it  probably  has 
sequential  or  communicational  binding. 

2.  If  the  sentence  contains  words  relating  to 
time,  such  as  "first",  "next",  "then",  "after",  "when", 
"start",  etc.,  then  the  module  probably  has 
sequential  or  temporal  binding. 

3.  If  the  predicate  of  the  sentence  doesn't 
contain  a  single  specific  object  following  the  verb, 
the  module  is  probably  logically  bound.  For 
example.  Edit  All  Data  has  logical  binding:  Edit 
Source  Statement  may  have  functional  binding. 


4.  Words  such  as  "initialize",  "clean-up",  etc., 
imply  temporal  binding.  Functionaliy  bound 
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modules  can  always  be  described  by  way  of  their 
elements  using  a  compound  sentence.  But  if  the 
above  language  is  unavoidable  while  still 
completely  describing  the  module's  function,  then 
the  module  is  probably  not  functionally  bound. 


Source:  Pressman,  p  335 


IS 


L250H7 


Costs  As  Function  of  Cohesion  Levei 


Cohesion 

level 

Coupling 

Cleanli¬ 
ness  of 

imple¬ 

mentation 

Modifia¬ 

bility 

Under- 

standa- 

bility 

Efibcton 

overall 

system 

maintain¬ 

ability 

Functional 

Good 

Good 

Good 

Good 

Good 

Ssquential 

Good 

Good 

Good 

Good 

Fairly  good 

Communi- 

cational 

Medium 

Medium 

Medium 

Medium 

Medium 

Procedural 

Variable 

Poor 

Variable 

Variable 

Bad 

Temporal 

Poor 

Medium 

Medium 

Medium 

Bad 

Logical 

Bad 

Bad 

Bad 

Poor 

Bad 

Coinci¬ 

dental 

Bad 

Poor 

Bad 

Bad 

Bad 

■Mrtn  FciWnm 
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Coupling  Spectrum 


A  Mcanretflkehliritpcidcicc 
Aatif  Mlvm  M«4iki 


IftMrMt 


lUmii 


PrMBM,  Film  mil 
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Content- 
Common  - 

Control  - 

Stamp  - 

Data  - 


COUPLING  LEVELS 

One  refers  to  internals  of  other 

Have  access  to  same  global  data 
area 

Communicate  at  least  one 
element  of  control 

Communicates  a  data  structure 
and  the  called  module  operates 
on  some  but  not  all  of  the 
individual  components  of  the  data 
structure 

Only  parameters  communicated 
or  a  data  structure  in  which  all  of 
the  elements  are  needed  by  the 
called  module 
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Coupling  Exwnplos  (Schach) 
Module  Interconnection  Diagram  for 
Coupling  Exampte 


Interfa 

ce  Description 


Number 

In 

Out 

1 

aircraft  type 

status  fiag 

2 

.... 

list  of  aircraft 
parts 

3 

function  code 

.... 

4 

.... 

list  of  aircraft 
parts 

5 

part  number 

part 

manufacturer 

6 

part  number 

part  name 

Coupling  Between  Pairs  of  Modules 
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a.  Are  we  building  the  right  product? 

Validation  involves  checking  that  the  program  as  implemented 
meets  the  expectations  of  the  customer  as  specified  in  the 
requirements  specification  documentation,  in  other  words,  we 
want  to  demonsfrate  through  tests  whether  or  not  the  software 
product  meets  the  customer's  expectations.  The  completed 
end  product  is  tested. 


c.  Dynamic  analysis  is  the  primary  technique  used  in 
accomplishing  validation. 


4.  Discuss  verification  and  validation  activities  of  each  phase  of  the 
traditional  process  model  are  examined.  L210H5.  L210H6  L210H7 
-Review  of  software  products  is  traced  back  to  its  requirements. 
L210H8.  L210H9  -  Maintenance  is  a  reiteration  of  the  software 
development  life  cycle.  Maintenance  also  re-applies  previous  test 
cases  to  assure  no  loss  of  functionality  during  maintenance  changes. 


5.  Acceptance  criteria  are  important  in  the  accomplishment  of  validation. 
Without  established,  agreed  upon  criteria  by  which  to  judge  validation, 
certification  of  customer  satisfaction  is  difficult.  The  role  of  acceptance 
criteria  within  the  software  requirements  specification  is  discussed. 
The  acceptance  tests  provide  predefined  criteria  for  functionality, 
performance,  interface  quality,  and  other  identified  quality  attributes. 

L21OH10 

6.  The  acceptance  criteria  described  above  are  often  called  explicit 
requirements  because  the  customer  has  explicitly  stated  them  in  the 
software  requirements  specification.  There  is  another  type  of 
requirements  which  developers  need  to  be  concerned  about;  these 
requirements  are  called  implicit  requirements.  Implicit  requirements 
are  quality  factors  which  the  customer  desires  or  expects  in  the 
software  but  may  not  explicitly  state.  Examples  of  implicit 
requirements  include  reliability  and  robustness. 

L210H11 

7.  The  activities  of  verification  and  validation  should  be  thoroughly 
planned  and  documented  in  a  Software  Verification  and  Validation 
Plan.  This  document  serves  as  the  blueprint  for  all  V&V  activities. 
Give  examples  of  the  major  bullets  on  this  overhead. 
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EBQCEDURE: 

tBachino  mrthod  and  media: 


vocabulary  introduced: 
verification 
validation 
acceptance  criteria 
static  analysis 
dynamic  analysis 
formal  analysis 


IMSTRUCTiONAL  MATERiALS: 
overheads: 

L210H1  Verification  and  Validation 

L210H2  Types  of  Analysis  Used  in  Verification  &  Validation 

L210H3  Verification 

L210H4  Validation 

L210H5  Requirements  Analysis  and  Definition  Phase 

L210H6  Design  Phase 

L210H7  Implementation  Phase 

L210H8  Testing  Phase 

L210H9  Maintenance  Phase 

L21OH10  Framework  for  a  Software  Requirements  Specification 
L210H1 1  Software  Verification  and  Validation  Plan 

handouts: 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exerdses) 

Lab  018  -  Preliminary  requirements  presentation/review 

Preliminary  users  manual  presentation  and  review 
READiNG  ASSIGNMENTS: 

Sommerville  Chapter  19  (pp.  373-386) 

Sommerville  Chapter  22  (pp.  425-439) 

RELATED  READINGS: 

Ghezzi  Chapter  6  (pp.  255-344) 

Pressman  Chapter  19  (pp.  632-663) 
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Verification  and  Vaiidation  (V&V) 


Major  approaches  within  software  engineering 
process  models  for  ensuring  the  production  of 
quality  software 

Complementary  but  distinct 

Continuing  process  through  each  stage  of 
software  life  cycle 

Two  objectives: 

1 .  Discovery  of  defects  in  any 
development  product 

2.  Assessment  of  whether  or  not  the 
system  satisfies  specified 
requirements 

Types  of  analysis; 

Static  analysis 

Dynamic  analysis 

Formal  analysis 


L210H1 


Type*  of  Analyolo  Used  in  V&V 


Static  Analysis 

No  execution  involved 
Manual  or  automated  examination 

examples: 

Software  reviews 
Static  program  analyzers 


Dynamic  Analysis 
Execution  involved 

Examines  functional,  structural,  or 
computational  aspects  of  software 
examples: 

Unit  testing 
integration  testing 
Acceptance  testing 

Formal  Analysis 

Use  of  mathematical  techniques  to 

evaluate  product 

examples: 

Symbolic  execution 
Proof  of  correctness 
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Verification 


Are  we  building  the  product  right? 


Evaluate  the  end  product  of  each  phase 


Look  for  errors  generated  within  a  phase 
and/or  by  the  transformation  between  phases 


Tasks  are  to  assume  that  the  products  of 
each  software  life  cycle  phase: 

1 .  Comply  with  previous  life  cycle  phase 
requirements  and  products 

2.  Satisfy  the  standards,  practices,  and 
conventions  of  the  phase 

3.  Establish  the  proper  basis  for  initiating 
the  next  life  cycle  phase  activities 
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Validation 


Are  we  building  the  right  product? 


Checking  that  the  system  as  implemented 
meets  the  expectations  of  the  software 
procurer/customer 


Tasks  are  to  validate  that  the  end  product 
complies  with  estabiished  software  and 
system  requirements 


8 


L210H4 


RMi^itaamwito  Ana^ls  and  DaflnMon  Plwaa 


Verification  activities: 

Formai  review  of  requirements 
spe^cation  document 
Review  of  project  plan  document 
Review  of  preliminary  user  manual 


Validation  activities: 

Delineation  of  acceptance  criteria 
Generation  of  requirements-based  test 
cases 


Development  of  Project  V&V  Plan 
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Design  Phase 


Verification  activities: 

Formai  review  of  design  documents 
Review  of  Project  V&V  Pian 
Generation  of  test  pians  for  unit,  design- 
unit,  and  system  testing 
Generation  of  design-based  test  cases 
Review  of  test  plans 


Validation  activities: 

Generation  of  test  plan  for  acceptance 
testing 

develop  a  requirements  traceability  matrix 


Completion  of  Project  V&V  Plan 
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Implementation  Phaee 


Verification  activities: 

Review  of  software  products 
Unit  testing 

Generation  of  code-based  test  cases 


Vaiidation  activities: 

Oeveiop  a  component  to  design 
traceabiiity  matrix 
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Testing  Phase 


Verification  activities: 

Generation  of  code-based  test  cases 
Design  unit  testing 
System  testing 


Validation  activities: 
System  testing 
Acceptance  testing 


L210H8 


Maintenance  Phaee 


Verification  activities: 

Aii  previous  activities 

Vaiidation  activities: 

All  previous  activities 
Regression  testing 

Generation  of  test  cases  for  validating 
modifications 
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Framework  for 

Software  Requirementa  Specification 

1  Introduction 

1.1  System  reference 

1 .2  Business  objectives 

1 .3  Software  project  constraints 

2  Software  description 

2.1  Objects  and  operations 

2.2  Flow  model 

2.3  Data  dictionary 

2.4  System  interface  dictionary 

3  Processing  narratives 

3.n  Transform  n  description 
3.n.1  Processing  narrative 
3.n.2  Restrictions/limitations 
3.n.3  Performance  requirements 
3.n.4  Design  constraints 
3.n.5  Supporting  diagrams 

4  Validation/acceptance  criteria 

4.1  Testing  strategy 

4.2  Classes  of  tests 

4.3  Expected  software  response 

4.4  Special  considerations 

5  Bibliography 

6  Appendix 


14 


L21OH10 


Software  Verification  and  Validation  Plan 


Plan  for  the  conduct  of  software  verification  and 
vaiidation 

Outline: 

1 .  Purpose 

2.  Referenced  Documents 

3.  Definitions 

4.  Verification  and  Validation  Overview 

4.1  Organization 

4.2  Master  schedule 

4.3  Resources  summary 

4.4  Responsibilities 

4.5  Toois,  techniques,  and  methodologies 

5.  Life  Cycle  Verification  and  Validation 

5.1  Management  of  V&V 

5.2  Concept  Phase  V&V 

5.3  Requirements  Phase  V&V 

5.4  Design  Phase  V&V 

5.5  Implementation  Phase  V&V 

5.6  Test  Phase  V&V 

5.7  Installation  and  Checkout  Phase  V&V 

5.8  Operation  &  Maintenance  Phase  V&V 
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Software  Verification  and  Validation  Plan 


Outline  (cont.): 

6.  Software  Verification  and  Validation 
Reporting 

7.  Verification  and  Validation  Administrative 
Procedures 

7.1  Anomaly  reporting  and  resoiution 

7.2  Task  iteration  policy 

7.3  Deviation  poiicy 

7.4  Control  procedures 

7.5  Standards,  practices,  and  conventions 


Source  :  IEEE 
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LECTURE  NUMBER:  022 


TOPICrS)  FOR  LECTURE: 
Testing 


INSTRUCTIONAL  OBJECTtVEfSL 


1.  To  undeistarKl  the  rote  of  testing  within  verification  and  validation  and 
the  software  life  cyde. 

2.  To  recognize  the  different  types  of  tasting  and  the  purpose  of  each. 


SET  UP.  .WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

(Learning  Label*  Today  we  are  going  to  learn  ...) 

In  previous  classes,  we  have  talked  about  the  production  of  quality  software 
and  the  use  of  verification  and  validation.  Today  we  will  be  examining  one 
aspect  of  verification  and  validation  in  detail  **  testing. 


CONTENTS: 

L220H1 

1.  Testing  is  often  confused  with  verification  and  validation;  however, 
testing  is  only  one  component  of  the  verification  and  validation. 

Testing,  according  to  the  IEEE  definition,  is  "the  process  of  exercising 
or  evaluating  a  system  by  manual  or  automatic  means  to  verify  that 
it  satisfies  specified  requirements  or  to  identify  differences  between 
expected  and  actual  results.”  Testing  is  designed  to  reveal  defects. 
It  shows  where  a  system  Is  correct  and  where  it  is  wrong.  Note  that 
testing  and  debugging  are  different;  testing  reveals  the  existence  of 
defects  while  debusing  locates  and  corrects  them.  In  the  1960's  and 
1970's,  it  is  estimated  tiiat  over  50  percent  of  development  time  and 
development  costs  were  spent  on  testing.  During  this  time,  people 
were  attempting  to  test  quality  into  the  software  instead  of  building 
quality  into  softmre  from  the  thinning  of  the  life  qrde  as  verification 
and  validation  attempts  to  do  now. 


L220H2 

2.  Discuss  the  prindpies  of  testing  which  were  presented  by  Mynatt. 
L220H3  Note  the  difference  of  emphasis  from  the  IEEE  definition, 
Mynatt  focuses  on  error  detection  while  the  IEEE  definition  focuses  on 
showing  correctness.  Point  out  that  the  first  four  steps  can  and 
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should  be  done  as  a  part  of  requirements  analysis.  If  a  dear  set  of 
tests  cannot  be  written  during  analysis,  the  indicates  that  the 
requirements  are  not  dear. 

L220H4 

3.  The  three  primary  types  of  testing  are  unit  or  module  testing, 
integration  testing,  and  acceptance  testing.  Unit  or  module  testing  is 
performed  during  the  implementation  phase  by  the  programmer  who 
is  building  the  module. 

a.  The  primary  goals  of  unit/module  testing  are  to  ensure  that  the 
module  operates  correctly  and  that  it  carries  out  its  intended 
fundion,  and  to  identify  the  presence  of  defects.  This  is 
generally  done  by  the  implementor. 

b.  Integration  testing  is  the  testing  of  groups  of  integrated 
modules  (or  subsystems)  or  the  entire  system.  The  most 
common  types  of  integration  testing  are  design  unit  and  system 
testing.  Design  unit  testing  first  uses  design  information  in 
selecting  the  modules  to  integrate  and  test.  This  is  based  on 
the  structure  chart.  System  testing  is  testing  of  the  whole 
system.  This  is  an  internal  acceptance  test  in  a  simulated 
environment.  The  goals  of  integration  testing  are  to  determine 
if  the  subsystem  of  modules  or  system  meets  requirements  and 
functions  properly  and  to  test  the  interface  among  the  modules 
or  subsystems. 

c.  Acceptance  testing  is  performed  on  the  finished  product  in  the 
operational  environment.  This  type  of  testing  is  carried  out  by 
the  sponsor/customer.  The  goal  of  acceptance  testing  is  to 
demonstrate  that  the  system  is  ready  to  use  and  that  it  meets 
all  the  customer's  requirements  and  satisfies  ail  acceptance 
criteria. 

L220H5 

c.  Discuss  the  interaction  between  the  various  types  of  testing. 


L220H6 

4.  A  primary  concern  in  performing  testing  is  the  generation  of  test 
cases.  You  want  to  generate  enough  test  cases  to  thoroughly 
exercise  the  software  but  not  so  many  test  cases  as  to  make  thorough 
analysis  of  the  test  results  impossible.  Exhaustive  testing,  which  tests 
every  input  and  exercises  every  line  of  the  software,  is  the  technique 
to  use  to  thoroughly  test  software,  but  it  is  computationally  impossible 
and  time-wise  too  expensive.  Alternatives  to  exhaustive  testing 
include  functional  analysis,  structural  analysis,  and  data-structure- 
based  analysis.  These  are  three  complementary  approaches  to  the 
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generation  of  test  cases. 


L220H7 

5.  Functional  testing,  black  box  testing.is  based  on  functionality,  inputs, 
and  outputs  of  a  module  with  no  regard  to  the  internal  workings  of  the 
module.  Three  techniques  for  deriving  test  cases  for  functionai  testing 
are  equivalence  partitioning,  cause-effect  strategy,  and  boundary 
values  strategy. 

Discuss  examples  for  each  technique  for  deriving  functional  test  cases 
and  work  through  the  exercises  with  the  class.  L220H8,  L220H9, 
L22OH10.  L220H11,  L220H12,L220H13,  L220H14,  L220H15, 
L220H16.  suggested  partitions  for  L220H1 1  include:  first  character 
alphabetic  and  non-aiphabetic;  length  less  than  6,  greater  than  10, 
and  between  6  and  10  inclusive;  valid  and  invalid  characters;  and 
passwords  which  are  and  are  not  in  the  dictionary. 


6.  Structural  testing  is  based  on  the  internal  logic  of  a  module.  L220H17 
The  concept  of  coverage  analysis  is  used  in  structural  testing.  The 
types  of  coverage  include  statement,  decision,  condition,  and  path. 
Discuss  examples  L220H18.  L220H19,  L22OH20.  L220H21. 
L220H22 


7.  In  performing  integration  testing,  common  methods  of  integration  are 
used  in  grouping  the  modules  or  subsystems  for  testing.  These 
methods  are  top-down  testing,  bottom-up  testing,  thread  testing,  and 
stress  testing.  L220H23 


8.  Many  testing  and  debugging  tools  are  available  in  today's 
development  environments.  Some  of  these  tools  include  static 
analysis  tools,  dynamic  analysis  tools,  test  data  generators  and 
oracles,  fife  comparators,  and  simulators.  L220H23 


EBOCEDUBE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  this  lecture. 

vocabulary  introduced: 
testing 

unit  testing/module  testing 
integration  testing 
design  unit  testing 
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dsbuQflino 
syilsfn  tstlinQ 
iftfttffrtincft  tBtlinQ 
exhtusliv«  t0Sling 
functional  analysis 
stnicturai  anal)^ 
date-stnictura-toasad  tsstino 
equivaienoe  partitioning 
cause-affact  stratagy 
boundary  values  strategy 
statement  coverage 
decision  coverage 
condition  coverage 
path  coverage 
top^town  testing 
bottom-up  testing 
thread  testing 
stress  testing 
static  analysis  tools 
dynamic  analysis  tools 
test  data  generators 
test  oracles 
file  comparators 
simulators 


L220H1  Testing 

L220H2  Steps  of  Testing 

I.220H3  Prindpies  of  Testing 


L220H4  Types  of  Testing 
L220H5  V&V  Testing  Activities 

L220H6  Generation  of  Test  Cases 


L220H7  Functional  Testing 

L220H8  Equivaienoe  Partitioning 

L220H9  Examples  of  Equivaienoe  Partitioning 

L22OH10  Test  Matrix  for  Equivaienoe  Partitioning 
L220H1 1  Exercise  on  Equivalence  Partitioning 


L220H12  Cause-effect  Strategy 
L220H13  Example  of  Cause-effect  Strategy 

L220H14  Test  Matrix  for  Cause-effect  Strategy 


L220H15  Boundary  Value  Analysis 

L220H16  Examples  of  Boundary  Value  Ar  liiysis 

L220H17  Structural  Testing 


L220H18  Statement  Coverage 
L220H19  Example  of  Statement  Coverage 

L22OH20  Decision  Coverage 

L220H21  Condition  Coverage 
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L220H22  Testing  StrUiglM 
L220H23  Tstlino  and  Dsbuggino  Tools 

handouts: 


BELATEP  LEAfflINQ  AC1 

(labs  and  exercises) 


Lab  019  -  Preliminary  test  plan  presentatlonhevisw 
READING  ASSIGNMENTS: 

SommerviHe  Chapter  23  (pp.  441-454) 

Sommervilie  Chapter  24  457-473) 

Mynatt  Chapter  7  (pp.  274-316) 


RELATED  READINGS: 

Booch  Chapter  23  (pp.  420-421) 
Booch(2)  Chapter  19  (p.  402) 
Qhezzi  Chapter  6  (pp.  260-293) 
Pressman  Chapter  18  (pp.  595-626) 
Schach  Chapter  12  (pp.  385-416) 
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Testing 


The  process  of  exercising  or  evaluating  a  system 
by  manual  or  automatic  means  to  verify  that  it 
satisfies  specified  requirements  or  to  identify 
differences  between  expected  euid  actual  results 


An  aspect  of  verification  and  validation 
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Steps  of  Testing 


1 .  Select  what  is  to  be  measured  by  the  test 


2.  Decide  how  whatever  is  being  tested  is  to 
be  tested 


3.  Develop  the  test  cases 


4.  Determine  what  the  expected  or  correct 
result  of  the  test  should  be  and  create  the 
test  oracle 


5.  Execute  the  test  cases 


6.  Compare  the  results  of  the  test  to  the  test 
oracle 
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Principles  of  Testing 


Testing  is  the  process  of  executing  a  program  with 
the  intention  of  finding  errors. 


It  is  impossible  to  completely  test  any  non-trivial 
module  or  any  system. 


Testing  takes  creativity  and  hard  work. 


Testing  can  prevent  errors  from  occurring. 


Testing  is  best  done  by  several  independent 
testers. 
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Types  of  TMtIng 


Unit  testing/module  testing 

Integration  testing 
Design  unit  testing 
System  testing 

Acceptance  testing 
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V  &  V  Testing  Activities 
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Generation  of  Test  Cases 


Exhaustive  testing 


Aiternatives  to  exhaustive  testing; 
Functionai  anaiysis 
Structurai  analysis 
Data-structu  re-based  testing 
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Functional  Testing 


The  specification  of  external  behavior  is  used 
to  derive  test  cases 

Aiso  calied  biack-box  method 

Techniques  to  deriving  test  cases: 
Equivaience  partitioning 
Cause-effect  strategy 
Boundary  values  strategy 
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Equivalence  Partitioning 


A  equivalence  partition  consists  of  a  class  or 
set  of  data  items  all  of  which  are  similar  to 
each  other  on  some  relevant  dimension 


Divide  input/output  into  finite  number  of 
equivalence  partitions 

Take  each  input/output  condition  and 
divide  it  into  2  or  more  groups  --  valid 
equivalence  partitions  and  invalid 
equivalence  partitions 

Test  one  item  from  each  partition 
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Examples  of  Equivalence  Partitioning 

Specifications  for  Customer  Number 

Customer  numbers  must  be  within  the  range 
1-32700  inclusive  without  9  in  the  unit 
positions 

Partition  into: 

non-numeric  value  and  numeric  value 

test  groups 
1  -32700 
<  1 

>  32700 

9  in  unit  position 
<  9  in  unit  position 
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Test  Matrix  for  Equivalence  Partitioning 

Using  the  specification  of  the  Customer 
Number: 

Partitions  or  equivalence  classes 
Number  value  1  non-numeric 

2  numeric 
Range  3  1  -32700 

4  <1 

5  >32700 

Unit  Position  6  9 

7  <9 


Equivalence 

Test  Cases 

Class  Entries 

1  2  3  4  5  .... 

1 

X 

2 

XXX 

3 

X 

4 

X 

5 

X 

6 

X 

7 

X 

Test  Cases: 

1.  32708  4.  1AB 
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2.  0  5.  009 

3.  2708 
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Exercise  of  Equivalence  Partitioning 


Validate_New_Password  accepts  a  password  from 
a  user  and  validates  that  it  conforms  to  the 
following  rules: 

1.  A  password  must  be  between  6-10 
characters  inclusive 

2.  The  first  character  must  be  alphabetic 

3.  The  remaining  characters  may  be  any 
character  except  control  characters 

4.  The  password  must  not  be  in  a  dictionary 


Exercise:  Develop  the  test  matrix  for 
equivalence  partitioning. 
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Caus»«ffaet  Strategy 


Tests  combinations  of  inputs 


Causes  (inputs)  and  effects  (outputs)  are 
identified 
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Example  of  Cause-effect  Strategy 


Determine_Max_Load  accepts  the  GPA  for  a 
student  and  the  level  of  the  student  (uppercleiss  or 
lowerclass)  and  calculates  and  outputs  the 
maximum  class  load  which  the  student  may  take 
during  one  semester.  If  the  student  has  a  GPA  of 
4.0,  he/she  has  a  maximum  class  load  of  20.  If 
the  student  has  a  GPA  of  3.5  or  better,  he/she 
has  a  maximum  class  load  of  1 8.  If  the  student 
has  a  GPA  of  less  than  3.5  and  is  an 
upperclassmen,  he/she  has  a  maximum  class  load 
of  1 8.  If  the  student  has  a  GPA  of  less  than  3.5 
and  is  an  lowerclassmen,  he/she  has  a  maximum 
class  load  of  1 6. 


Causes 

GPA 

4.0 

3.5  or  higher 
<3.5 

Level 

upperclass 

lowerclass 

Effects 

20 

18 

16 
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Test  Matrix  for  Cause-effect  Strategy 


Causes 
GPA  4.0 
GPA  >=  3.5 
GPA  <  3.5 
upperclass 
lowerclass 


Test  Cases 

12  3  4  5 
X  X 

X  X 
X 

X  X 

X  XX 


£ 

X 

X 


Effects 

20  XX 

18  XXX 

16  X 


Test  Cases: 

1 .  Upperclass  with  4.0 

2.  Lowerclass  with  4.0 

3.  Upperclass  with  3.75 

4.  Lowerclass  with  3.4 

5.  Lowerclass  >=  3.5 

6.  Upperclass  >=  3.5 
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Boundary  Value  Analysis 


Boundary  conditions  are  the  situations  directly 
on,  above,  and  below  the  edges  of  input 
equivalence  classes 


Include: 

<  Beginning  element 
Beginning  element 
Middle  element 
End  element 
>  end  element 
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Examples  of  Boundary  Value  Analysis 


Specifications  for  Caicuiating  Pay 

Compute  gross  pay  inciuding  overtime  rate  for 
hours  over; 

Partitions  <  40 
=  40 
>40 

Boundary  vaiues  are  0  and  40 

Test: 

<0 

0-40 

>40 

Sampie  of  test  vaiues: 

-1  outside  of  low  boundary, 

0  at  the  low  boundary, 

20  middle  value, 

40  at  upper  boundary, 

41  above  upper  boundary 
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structural  Testing 


Approach  to  testing  where  the  internal  logic  of 
a  module  is  used  to  derive  test  cases 

Also  called  white-box  or  glass-box  testing 

Techniques  to  derive  test  cases: 

Statement  coverage 
Decision  coverage 
Condition  coverage 
Path  coverage 


23 


L220H17 


statement  Coverage 


Develop  test  cases  such  that  every  statement 
is  executed  at  least  once 


May  be  too  much  test  data 


Does  not  test  all  logic  (e.g.,  combination  of 
statements 


24 


L220H18 


Example  of  Decision  Coverage 


1 .  if  (ORDER  >=  20)  or  (CUSTOMER  =  'G') 
then  DISCOUNT  :=  10 
else  if  (ORDER  >=  10)  or  (CUSTOMER  =  'E') 
then  DISCOUNT  :=  7 

else  if  (ORDER  <  20)  and  (CUSTOMER  =  'V') 
then  DISCOUNT  :=  5 

6ls@ 

DISCOUNT  :=  0; 


2.  if  CUSTOMER  = 'G' 
then  VIP  :=  true 
else 

VIP  :=  false; 

T©st  Ocis@s* 

1 .  20  and  'G'  =>  DISCOUNT  =  10  and  VIP  =  true 

2.  12  and  'E'  =>  DISCOUNT  =  7  and  VIP  =  false 

3.  12  and  'V  =>  DISCOUNT  =  5  and  VIP  =  false 

4.  9  and  'S'  =>  DISCOUNT  =  0  and  VIP  =  false 
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Decision  Coverage 


Develop  test  cases  such  that  each  branch  is 
traversed  at  least  once 


What  are  examples  of  branch  statements? 

Does  decision  coverage  satisfy  statement 
coverage? 
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Condition  Coverage 


Develop  test  cases  such  that  all  combinations  of 
truth  values  in  a  decision  takes  are  tested  at  least 
once 


What  are  examples  of  conditions? 


Does  condition  coverage  satisfy  decision 
coverage? 

What  must  be  added  to  decision  coverage  to 
change  it  to  condition  coverage? 
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Testing  Strategies 


Top-down  testing 


Bottom-up  testing 


Thread  testing 


Stress  testing 
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Testing  and  Debugging  Toois 


Static  analysis  tools 


Dynamic  analysis  tools 


Test  data  generators  and  oracles 


File  comparators 


Simulators 
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TQPICfS^  FOR  LECTURE: 

More  on  the  Structured  .Analysis  model 

INSTRUCTIONAL  QBJECTiVE(S): 

1.  Understand  the  concept  and  representation  of  control  flows  and  control 
transforms  in  OFDs. 

2.  Understand  use  of  process  specifications  and  control  specificatior«  to 
describe  primitive  transforms. 

3.  Know  that  a  wide  range  of  methods  for  writing  process  and  control 
spedficalfons  exist  and  be  famHfar  with  a  number  of  them,  including 
narrative  English,  pseudocode,  decision  tables,  decision  trees,  graphs, 
functions,  finite  state  machines,  and  Petri  nets. 

SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

You  are  fomUiar  with  many  aspects  of  the  structured  analysis  model,  having  used 
it  in  your  first  prefect.  You  produced  a  CD,  a  leveled  and  balanced  set  of  DFDs, 
and  an  integrated  data  dictionary. 

(Learning  Label-  Today  we  are  going  to  learn ...) 

Today  we're  going  to  dtecuss  some  additional  aspects  of  that  structured  analysis 
model. 


CONTENTS: 

1.  Review  the  structured  analysis  model  already  presented  and  discuss 
some  further  aspects. 

a.  Context  diagram  shows  the  net  inputs  and  net  outputs  of  the 
system,  it  shows  no  decomposition  of  the  system.  It  is  the  first 
level  of  the  model  and  depicts  the  relalionship  between  the  system 
and  the  sources  and  destinations  of  the  system's  inputs  and 
outputs. 

b.  DFDs 

i  Naming  of  transfonns  >  the  transforms  represent  actions 
(functions)  and  should  be  named  as  meaningful  as 
posafoiey^inonlyafewwords.  Thenameoonsistsofan 
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action  verb  indlcatir^  the  function  to  be  performed  followed 
by  an  object  (noun)  or  adjective/noun.  Generic  names 
(e.g.  Process  input,  or  Handle  transaction)  that  convey  little 
knowledge  of  the  transform's  function  must  be  avoided. 

ii  Naming  of  data  flows  -  data  flovtrs  are  named  vectors 
representing  "data  in  motion".  They  must  also  be  named 
concisely  but  meaningfully.  Data  flow  names  are  always 
nouns. 

iii  Control  flows  -  a  data  flow  that  represents  an  element  of 
control  (a  flag,  switch,  command  signal,  etc.)  is  called  a 
control  flow.  Generally  control  flows  are  not  shown  (for 
example,  every  transform  has  a  "trigger"  that  invokes  it)  but 
at  times,  particularly  in  real-time  systems,  control  flows  are 
modeled.  A  control  flow  is  indicated  as  a  dashed  vector. 
A  transform  that  handles  only  control  flows  may  be 
represented  by  a  dashed  circle  rather  than  a  solid  circle. 
Such  a  transform  is  called  a  control  transform. 

iv  Extensions  for  real-time  systems  -  There  are  a  number  of 
extensions  to  the  basic  structured  analysis  notation 
intended  to  better  model  real-time  systems.  Discuss  these 
briefly  in  order  to  let  students  know  that  these  extensions 
exist  and  that,  without  them,  real-time  systems  cannot  be 
adequately  modeled.  Pressman  provides  an  excellent 
discussion  of  these  extensions. 

V  Placement  of  data  stores  -  are  they  shown  on  multiple 
levels?  where  are  they  shown?  In  general,  a  data  store  is 
shown  on  the  diagram  in  which  it  first  appears  as  an 
interface  between  two  transforms. 

vi  Review  concept  of  decomposition  (leveling),  balancing. 


Discuss  how  one  knows  when  to  stop  leveling. 

a.  Leveling  continues  until  a  transform  is  identified  that  cannot  be 
further  decomposed.  A  transform  that  cannot  be  further 
decomposed  is  called  a  functional  primitive,  or  simply  a  primitive. 
While  there  are  no  rules  for  recognizing  a  primitive,  there  are  a 
number  of  guidelines.  Discuss  these; 

i  the  transform  is  a  simple,  obvious,  or  well-known  function 
and  further  decomposition  is  dearly  unnecessary 
Ii  the  transform  has  a  single  input  and  a  single  output 
iii  the  policy  governing  the  transform  can  be  easily  and  dearly 
described  on  a  single  page 

b.  A  process  spedfication  is  then  written  for  each  primitive.  Process 
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specifications  are  also  referred  to  as  process  specs,  p-specs,  or 
mini-specs.  A  process  specification  provides  a  detailed 
explanation  of  tfw  internal  processing  policy  of  a  primitive. 
Discuss  some  forms  of  process  specifications  that  students  are 
already  familiar  with,  e.g.  pseudocode. 

Process  specifications  (P-specs  or  mini-specs)  -  There  are  many  forms 
of  representing  process  specifications  with  varying  levels  of  formality. 
Use  examples  to  illustrate  a  variety  of  these  notations. 

a.  Narrative  English  is  perhaps  the  most  common  form  but  is  rarely, 
if  ever,  the  best  fomn.  Illustrate  using  the  verify  credit  transform 
desaibed  in  narrative  form  in  L230H1 . 

b.  L230H2 

Discuss  the  pseudocode  version  of  Verify  Credit  and  how  it  is  a 
significant  improvement.  Pseudocode,  or  structured  English, 
allows  logic  to  be  stated  dearly  and  unambiguously.  While 
informal,  standards  should  be  imposed  on  pseudocode  induding 
use  of  the  basic  control  structures,  and  reference  to  data 
dictionary  entries. 

C.  L230H3,  L230H4.  L230H5 

Discuss  further  examples;  different  styles. 

d.  L230H6,  L230H7 

Discuss  the  narrative  and  data  flow  diagram  description  of 
(L240H6)  a  transform  to  dedde  on  approval  for  a  loan.  This  is 
more  formally  and  more  effectively  represented  in  a  dedsion  table, 
as  shown  in  L210H7. 

e.  L230H8 

Discuss  the  same  example  represented  as  a  dedsion  tree. 
L230H9  Another  dedsion  tree  example. 


f.  Other  forms  -  Discuss  following  as  examples  of  other  forms  for 
process  specifications  and  stress  that  for  a  given  transform,  the 
most  appropriate  form  should  be  chosen. 

i  L23OH10  Rnite  state  machine  example 

ii  L230H11a.  L230H11b,  L230H12  Petri  net  examples 

iii  L230H13  Wamier  diagram  example  (for  data  store 
specification) 
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PROCEDURE: 


vocabulary  introduced: 
Control  flows 
Control  transforms 
Petri  net 
Decision  trees 
Decision  table 
Psuedocode 
Functional  primitive 
Finite  state  machine 
Wamier  Orr  diagram 


INSTRUCTIONAL  MATERIALS: 

overheads: 

L230H 1  Narrative  •  Verify  credit  transform 

L230H2  Psuedocode  Example  -  verify  credit 

L230H3  Another  Psuedocode  Example  - 

L230H4  Data  Dictionary  Example 

L230H5  Structured  Requirements  Specification 

L230H6  T ransform  from  DFD  with  narrative 

L230H7  Decision  table  for  loan  qualification 

L230H8  Decision  tree 

L230H9  Decision  tree  showing  flow  of  control 

L230H 1 0  Finite  State  Machines 

L230H11a  Petri  nets 

L230H11b  Petri  nets 

L230H1 2  Execution  of  a  Petri  net 

L230H 1 3  Wamier  diagram 


handouts: 


BELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  020  -  Final  requirements  presentation/review 
BEADING  ASSIGNMENTS: 

Sommerville  Chapter  4  (pp.  71-82) 

Mynatt  Chapter  2  (pp.  62-69) 

BELATED  READINGS: 

Ghezzi  Chapter  5  (pp.  160-198) 


4 


Lecture  023 


Pressman  Chapter  7  (pp.  207*235) 
Schach  Chapter  7  (pp.  157-193) 


5 


Lecture  023 


Narrative  Description  of  Verify  Credit 

"I  gather  together  all  of  the  orders  that  accumulated 
the  previous  day.  First  I  look  them  all  up  in  customer 
payment  history  file  and  I  pull  out  whatever  histories 
I  can  find.  Then  I  go  through  all  the  histories  and 
add  up  the  overdue  balances  and  mark  off  the  date 
of  the  oldest  balance.  Then  I  separate  the  records 
into  two  piles.  The  ones  that  have  no  overdue 
balance  or  even  a  balance  up  to  $1 00  go  to  Sally. 
She  also  gets  the  ones  that  aren't  more  than  60  days 
old  regardless  of  the  overdue  balance.  She  ok's 
credit  for  them.  All  the  rest  go  to  Jim  who  demands 
prepayments." 
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structured  English  Version  of  Verify  Credit 

FOR  each  Order 

Look  up  Customer_Payment_History  for 
Customer_Name  (on  Order) 

IF  no  record  found  (new  customer) 

THEN  Issue  a  Prepayment_Request 

ELSE  (existing  customer) 

Compute  Overdue_Balance 

IF  Overdue_Balance  >  1 00 
THEN  IF  Age_Of_Oldest.Balance  >  60 
days 

THEN  Issue 
Prepayment_Request 

ELSE  (overdue  less  than  61  days) 
Issue 

CrediL-Confirmation 

ELSE  (overdue  balance  <  $1 01 ) 

Issue  CreditjConfirmation 
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Prototyping  (Pressman) 


Itirt 
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Plan  to  Throw  One  Away 


In  most  projects,  the  first  system  built  is  barely 
usable.  It  may  be  too  slow,  too  big,  awkward  to  use,  or 
all  three.  There  is  no  alternative  but  to  start  again, 
smarting  but  smarter,  and  build  a  redesigned  version  in 
which  these  problems  are  solved.  The  discard  and 
redesign  may  be  done  in  one  lump,  or  it  may  be  done 
piece>by-piece.  But  all  large-system  experience  shows 
that  it  be  done.  Where  a  new  system  concept  or 
technology  is  used,  one  has  to  build  a  system  to  throw 
away,  for  even  the  best  planning  Is  not  so  omniscient 
as  to  get  It  right  the  first  time. 

The  management  question,  therefore,  Is  not 
whether  to  build  a  pilot  system  and  throw  It  away.  You 
will  do  that.  The  only  question  is  whether  to  plan  In 
advance  to  build  a  throwaway,  or  to  promise  to  deliver 
the  throwaway  to  customers.  Seen  this  way,  the 
answer  is  much  clearer.  Delivering  that  throwaway  to 
customers  buys  time,  but  it  does  so  only  at  the  cost  of 
agony  for  the  user,  distraction  for  the  builders  while  they 
do  the  redesign,  and  a  bad  reputation  for  the  product 
that  the  best  redesign  will  find  hard  to  live  down. 

Hence  plan  to  throw  one  away;  you  will,  anyhow. 

Source:  Brooks:  The  Mythical  Man-Month. 

1975,  p.  116. 
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The 


Model  (Sommerville) 
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LECTURE  NUMBER:  015 

TOPICfSI  FOR  LECTURE: 

Requirements  analysis  &  specification  structure 
An  introductory  discussion  of  requirements  identification 

INSTRUCTIONAL  OBJECTIVEfSI: 

1 .  Understand  the  goals  of  requirements  and  their  position  in  the  life 
cycle. 

2.  Understand  the  stages  in  requirements  development. 

3.  Be  able  to  use  language  syntax,  context  questions  and  elicitation  to 
develop  requirements. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

In  working  on  your  projects  you  have  no  doubt  come  to  realize  the 
importance  of  a  clear  understanding  what  is  to  be  developed  before  starting 
to  build  it.  In  software  development,  the  first  step  toward  such  a  clear 
understanding  takes  place  in  the  requirements  process.  The  completion  of 
this  process  is  marked  by  the  development  of  a  requirements  document, 
sometimes  called  a  software  requirements  specification. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  are  going  to  learn  about  the  stages  of  the  requirements  process 
and  the  structure  of  a  requirement  document. 


CONTENTS: 

1 .  Understand  requirements  in  terms  of  its  3  primary  goals.  The  first 
goal  is  paramount  during  early  stages  of  the  life  cycle  but  diminishes 
later  when  the  other  two  goals  become  more  important. 

a.  To  establish  agreement  about  a  system  between  the  sponsors, 
users  and  developers  of  a  system. 

b.  To  function  as  a  transition  from  the  problem  space  into  the 
solution  space  by  being  the  basis  for  software  design. 

c.  To  support  the  verification  and  validation  of  the  system. 


2.  The  requirements  process  and  document  address  the  goals  of 
requirements  listed  above. 
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a.  Requirements  definition  is  the  process  of  determining 
requirements  for  a  system.  The  audience  here  is  generally  the 
user  and  the  contractor. 

i  Software  requirements  are  distinguished  from  system 
requirements  when  the  software  requirements  are  part 
of  a  larger  system. 

ii  L150H1 

As  a  formal  description  of  the  understanding  between 
customer  and  software  developer,  introduce  the 
documentation  required  by  the  Department  of  Defense 
(DOD)  software  standard  2167a.  This  also  shows  the 
standards  for  formally  validating  these  documents. 

b.  The  details  of  the  initial  requirements  are  elaborated  in  a 
requirements  specification.  Sometimes  this  is  divided  into  high 
level  requirements  specification  which  talks  about  systems 
details  and  software  specification  which  is  a  dooiment 
addressed  to  system  designers.  Sometimes  these  are  stated 
formally,  allowing  a  high  degree  of  testability. 

3.  Requirements  validation  -  refer  back  to  LI  50H1 . 

There  are  several  distinct  tasks  which  must  be  accomplished  to 
identify  the  requirements.  This  process  is  referred  to  as  requirements 
definition. 

a.  Requirements  are  generally  elicited  from  people.  The  more 
complex  a  system  is,  the  more  likely  it  is  multiple  people  are 
involved  and,  thus,  multiple  viewpoints  exist. 

L150H2  illustrates  the  use  of  syntax  as  a  guide  to  identify  the 
actual  requirements.  Discuss  each  of  these  items  using  Koff 
as  an  example. 

b.  Linguistic  analysis  is  only  a  starting  point.  Other  techniques 
are  required  as  well.  Ask  the  class  for  techniques  they  would 
use  to  develop  the  requirements  for  a  medical  diagnosis 
system.  Bring  out  the  need  for  Interviewing  experts, 
understanding  the  environment  (including  the  equipment),  the 
technicians  using  the  equipment,  and  the  user  of  the  output  of 
the  system.  Then  discuss  the  techniques  below. 

i  Context  analysis  as  a  method  of  identification  asks  why 
the  software  is  created,  what  is  the  environment  of  the 
software,  and  what  are  the  operational,  economic 
boundary  conditions  that  acceptable  software  must 
satisfy.  The  result  of  this  is  called  software  needs  or 
system  needs  and  results  in  a  needs  report  which 
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should  be  included  in  a  software  requirements 
specification. 

ii  Elicitation  of  requirements  related  information  from  end- 
users.  subject  matter  experts  and  customers.  This  is 
both  a  fact  finding  and  validation  effort.  Fact  finding 
includes  Interviews,  questionnaires,  and  observation  of 
the  environment.  Validation  involves  presenting  results, 
including  documentation  and  prototypes,  to  the  customer 
and  resolving  open  issues. 

iii  Using  system  requirements  such  as  those  associated 
with  embedded  software. 

iv  Developing  user  interface  requirements.  Prototyping 
may  be  useful  here.  It  is  important  to  talk  to  the  user 
rather  than  the  customer  or  sponsor  at  this  point. 

c.  Identification  of  software  development  constraints:  cost, 
hardware, fault  tolerance. 

d.  There  are  several  other  tasks  in  requirements  analysis.  They 
involves  relating  all  of  the  requirements  gathered  from  diverse 
sources.  One  needs  to: 

i  assess  potential  problems; 

ii  classify  the  requirements  into  categories,  determine  a 
method  to  represent  the  requirements,  and  select 
validation  techniques.  These  will  be  discussed  in  later 
lectures. 


PaOgERLiRE: 

teaching  method  and  media: 
Lecture  and  overheads 

vocabulary  introduced: 

functional  requirements 
non-functional  requirements 
context  analysis 
requirements  elicitation 
linguistic  analysis 


INSTRUCTIONAL  MATERIALS: 

gyerliearis: 

L150H1  Software  requirements  analysis  -  DoD  standard  2167A 
L150H2  Requirements  identification  through  linguistic  analysis 


handouts: 
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aeiAIEP  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  013-  Peer/self  assessments  and  acceptance  reviews  for  small 
projects. 

READING  ASSIGNMENTS: 

Sommerville  Chapter  5  (pp.  85-103) 

Mynatt  Chajirter  2  (pp.  62-83) 

BELAIEP  nSADlNQS: 

Berzins  Chapter  2  (pp.  23-47) 

Pressman  Chapters  (pp.  173-189) 
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Software  Requirements  Analysis 
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Requirements  Identification  Through 
Linguistic  Analysis 

Statements  with  the  verbs  "shall",  "will",  "must",  "are",  or 
"Is". 

Statements  that  specify  numbers,  for  example,  limits, 
ranges  of  values,  or  tolerances. 

Statements  that  are  pre-defined  or  declarations  of 
requirements. 

Statements  that  specify  constraints. 

Statements  that  specify  size. 

Statements  that  define  dependencies,  relationships, 
sequence,  logical  flow,  or  behavior. 

Statements  that  specify  Interfaces,  inputs,  outputs,  events, 
or  interrupts. 

Statements  that  define  the  data. 

Statements  that  define  support. 

Statements  that  specify  the  environment. 

Statements  that  specify  human  processing. 

Statements  that  imply  requirements,  for  example, 
prerequisites. 
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LECTUBEHUMBEB:  016 

TQPiC(S)  FOB  LECTUBE: 

Ada  as  a  specification  tool  and  a  maintenance  tool 

INSTRUCTIONAL  OBJECTIVEfSI: 

1.  Understand  the  structure  of  Ada  systems  from  program  reading  of  an 
example. 

2.  Understand  the  interface  between  Ada  packages. 

SEI..UE..y^BM-UP: 

(How  involve  learner:  recall,  review,  relate) 

In  a  previous  lecture,  we  discussed  some  of  the  language  features  of  Ada 
which  support  design  and  maintenance  activities.  We  described  how  to  work 
from  the  products  of  the  analysis  phase  (i.e.,  requirements  list,  CD,  DFDs, 
data  dictionary)  to  derive  subsystems  which  compose  the  proposed  system. 
These  subsystems  contain  information  and/or  tasks  to  be  accomplished  in 
the  system  and  can  usually  be  classified  as  user  utilities,  resource 
mana^ment  utilities,  and  senrice  utilities.  Using  this  approach  to  high-level 
architecture  of  the  system  allows  a  high  degree  of  data  and  functional 
abstraction.  These  subsystems  can  then  be  shown  in  Ada  package 
specifications.  The  design  of  the  interface  for  these  packages  or  the 
subprograms  within  the  packacfos  allows  you  to  establish  what  information 
flows  to  and  from  these  subsystems  and  how  the  subsystems  Interact. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  are  going  to  look  at  another  problem  specification,  its  analysis,  and 
its  design. 

gQNTEfflS: 

1.  L16HD1 

Hand  out  and  discuss  the  narrative  description  of  the  spell  checker 
problem. 

Using  the  context  diagram  (L160H1)  and  the  first  level  DFD 
(L160H2),  discuss  how  to  determine  the  subsystems.  Possible 
subsystems  (and  their  actions)  include: 

a.  Main  dictionary  (look  up  a  word,  keep  a  counter) 

b.  Fast  dictionary  (look  up  a  word,  build,  keep  a  counter) 

c.  Auxiliary  dictionary  (look  up  a  word,  add  a  word,  keep  a 
counter) 
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d.  Word  (get  from  tir^e,  look  up  in  dictionaries,  handie  unknown 
word,  k^  a  counter) 

e.  Line  (get  from  file,  keep  a  counter) 

2.  L16HD2 

Provide  a  possible  solution  -  distribute  the  Ada  package 
specifications,  the  driver,  and  one  example  of  a  package  body. 

Using  L160H3,  show  the  students  how  these  pad^ages  and 
procedures  interact.  Discuss  the  design  of  the  software  system  as 
shown  in  these  packages.  Look  at  the  cohesiveness  and  coupling 
provided. 

3.  Examine  the  Ada  packages  for  the  spell  checker,  including  program 
features  of  Ada  and  the  maintainability  aspects  of  the  program. 
Generate  discussion  through  questions  about  making  modifications; 
e.g.  what  packages  would  be  affected  if  changes  were  made  to  the 
package  specification  of  Counter.  Test.ops,  and  Main_dict  or  the 
package  body  of  Test.ops. 

PRCX^EDURE: 

teaching  method  and  media: 


vocabulary  introduced: 
package  specification  and  body 


INSTRUCTIONAL  MATERIALS: 

overheads: 

L160H1  Context  diagram  for  Spelling  checker 

L160H2  Level  0  OFD  for  Spelling  checker 
L160H3  Structure  chart  for  Spelling  checker 

handouts: 

L16HD1  Spelling  checker  requirements 

L16HD2  Ada  package  specifications,  driver,  and  example  of  packs^ 
body 


RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 

Lab014  small  project  assessment 

READING  ASSIGNMENTS 
None 
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Context  Diagram 
Spell  Checker 


requ 

est 

s  command  +  name  of  input  file 
word  info  =  word  +  line 

direction  ^  ingnore  |  add  to  dictionary  |  correctly  spelled 
word 

statistics  =  number  of  tines  processed  -i-  number  of  words 
processed  +  number  of  words  found  in  main 
dictionary  •¥  number  of  words  found  in  fast 
dictionary  number  of  words  found  in  auxiliary 
dictionary 
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Spelling  Checker  Requirements 


Narrative: 

Spell  is  a  general-purpose  spelling  checker  that  operates  on  an  existing 
editor-created  text  file  to  produce  an  output  text  file  that  has  been  checked  for 
spelling  errors.  Spell  parses  out  the  words  from  an  input  file  and  compares  them 
with  entries  in  its  dictionaries.  Whenever  a  word  is  not  found  in  its  dictionaries,  the 
checker  will  indicate  the  word  and  the  line  of  text  that  contains  the  word  and  seek 
the  user's  directions  regarding  the  word. 

Spell  features  a  large  permanent  dictionary  accessed  from  disk,  as  well  as 
a  small  "fast”  dictionary  that  is  built  and  loaded  into  fast  memory  and  contains  the 
most  commonly  used  words  In  the  English  language.  In  addition,  an  auxiliary 
dictionary  that  contains  words  inserted  by  the  user  is  on  line.  This  auxiliary 
dictionary  is  the  only  one  that  may  be  modified  and  maintained  by  the  user. 
Unknown  words  that  are  correctly  spelled  may  be  automatically  added  to  the 
auxiliary  dictionary. 

In  addition  to  the  output  file.  Spell  will  provide  statistical  information  on  the 
file  which  was  processed.  This  information  includes  the  number  of  lines  of  text 
processed,  the  number  of  words  processed,  the  number  of  words  found  in  the  main 
dictionary,  the  number  of  words  found  in  the  fast  dictionary,  and  the  number  of 
words  found  in  the  auxiliary  dictionary. 

Spell  is  required  to  run  on  a  microcomputer  in  an  interactive  manner.  The 
microcomputer  must  have,  at  a  minimum,  a  video  terminal,  two  disk  drives  (floppy 
or  hard),  and  128,000  bytes  of  random  access  memory.  Spell  should  be  able  to 
process  at  least  200  words  per  minute. 
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package  COUNTERS  is 


type  COUNTER  is  limited  private; 

procedure  INITIALIZE  (C  :  out  COUNTER); 

-  used  to  initialize  an  object  of  type  COUNTER  to  zero 

procedure  INCREMENT  (C  :  in  out  COUNTER); 
used  to  increment  an  object  of  type  COUNTER  by  one 

procedure  DISPLAY  (C  :  in  COUNTER); 
used  to  display  the  value  of  an  otqect  of  type  COUNTER 

private  ^ 

type  COUNTER  is  new  integer; 
end  Counters; 
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with  Direct.io.  COUNTERS;  use  COUNTERS; 


package  TEXTjOPS  is 

~  from  DirecLio  import  type  FHeJype 
~  from  COUNTERS  imp^  type  COUNTER 

type  LINE  is  limited  private; 
type  WORD  is  limited  private; 

INPUT  :  Direct_io.File_type; 

END.OF.LINE,  LONG.WORO  :  boolean; 

-  END_OF_LINE  is  set  by  GET_LINE  to  true  at  the  erxt  of  a  line 

-  LONG.WORD  is  set  by  QET.NEXT.WORD  to  true  if  word  is  over 

-  13  characters 

function  GET_LINE  return  LINE; 

-  obtains  the  next  line  of  text  lor  processing 

function  GET_NEXT_WORD  (L  :  LINE)  return  WORD; 

~  obtains  the  next  word  in  line  for  processing 

procedure  GETJNPUT.TEXT  (NAME  :  In  String); 

-  fetches  an  existing  text  file  with  Name 

procedure  CREATE.OUTPUTJTEXT  (NAME  :  in  out  String); 

••  opens  a  new  text  file  Name 

procedure  PUT.OUTPUT  (L  :  in  LINE); 

••  sends  line  to  the  output  text  file 

procedure  WORD.HANDLER  (W :  in  WORD;  L  :  in  out  LINE; 

W.COUNT,  L_COUNT  :  in  COUNTER); 
handies  an  unidentified  word 

function  UPPERCASE  (W  :  WORD)  return  WORD; 

-  converts  a  word  to  uppercase 

function  SPECIAL_ENDING_1  (W :  WORD)  return  boolean; 

-  returns  true  if  word  ends  in  'S'  or  'D' 

function  SPECIAL_ENDING.2  (W  :  WORD)  return  boolean; 

-  returns  true  if  word  ends  in  'ED',  'ER',  or  'LV 

function  SPECIAL.ENDING_3  (W :  WORD)  return  boolean; 

» returns  true  if  word  ends  in  'EDS'.  'ERS',  or  'ING' 

function  STRIP.ENDINGJ  (W  :  WORD)  return  WORD; 

-  removes  'S'  or  'D'  ending  from  word 
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function  STRIP.ENOINQ_2  (W :  WORD)  return  WORD; 

-  removes  'ED',  'ER'  or  VC  ending  from  word 

function  STRIP_ENDING_3  (W  :  WORD)  return  WORD; 
removes  'EDS',  'ERS'  or  'iNG'  ending  from  word 

function  ING.ENDtNG  (W ;  WORD)  return  WORD; 

-  returns  true  if  word  e^  in  'ING' 

funcHon  ADD_E  (W  :  WORD)  return  WORD; 

--  adds  'E'  to  word 

procedure  DISPLAY^LINE  (L :  in  LINE); 

»  displays  a  line  on  a  video  terminal 

procedure  DISPLAY.WORD  (W :  in  WORD); 

-  display  a  word  on  a  video  teiminal 

procedure  REMOVE.APOSTROPHES  (W  :  in  out  WORD); 

-  removes  first  and  last  apostrophes,  if  present  in 
••  either  the  first  or  last  character  of  the  word 

function  LENGTH  (W :  WORD)  return  integer; 

••  returns  the  number  of  nonblank  characters  in  the  word 


private 

LINE_LENGTH  :  constant  :■  80; 

WORD^LENGTH  :  constant 13; 

type  LINE  is  array  (1..LINE_LENGTH)  of  character; 
type  WORD  is  array  (1  ..WORD_LENGTH)  of  character; 

end  TEXT^OPS; 
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with  TEXT^OPS;  use  TEXT.OPS; 


package  TEST.WORD  is 

-  from  TEXT.OPS  import  WORD 

function  IDENTIFY.WORO  (W :  WORD)  return  boolean; 
^  returns  true  whenever  word  is  found  in  one  of  the 

-  available  dictionaries 

end  TEST_WORD; 
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wfith  TEXT.OPS;  use  TEXT.OPS; 

package  MAIN.DICTis 

-  from  TEXT_OPS  Import  WORD 

NUM_FOUND_MD :  integer: 

~  NUM_FOUND_MD  is  ir)cremented  by  one  every  time  a  word 

-  is  found  in  the  main  dictionary 

procedure  CLOSE.MD; 

-  doses  the  main  dictionary  file 

function  LOOKUP.MD  (W  :  V^RD)  return  boolean; 

-  returns  true  if  word  is  found  in  main  dictionary 

end  MAIN.DICT; 
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with  TEXT_OPS;  use  TEXT_OPS; 


package  FAST_DiCT  is 

-  from  TEXT.OPS  Import  WORD 

NUM.FOUND.FD :  integer; 

-  NUM_FOUND_FD  is  incremented  by  one  every  time  a  word 

-  is  found  in  ttie  fast  dictionary 

procedure  CLOSE.FD; 

-  doses  the  fast  dictionary  file 

procedure  BUILD.FD; 

-  builds  fast  dictionary  file  from  main  dictionary 

function  LOOKUP_FD  (W :  WORD)  return  boolean; 

••  returns  true  if  word  is  found  in  fast  dictionary 

end  FAST.DICT; 
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with  TEXT_OPS;  ute  TEXT.OPS; 

package  AUX.DICT  is 

-  from  TEXT.OPS  import  WORD 

NUM.FOUND.AD :  integer; 

-  NUM^FOUND.AD  is  incremented  by  one  every  time  a  word 

-  is  found  in  the  auxiliary  dictionary 

procedure  CL08E_AD; 

-  doses  the  auxiliary  dictionary  file 

function  LOOKUP_AD  (W  :  WORD)  return  boolean; 

~  returns  true  if  word  is  found  In  auxiiiary  dictionary 

procedure  INSERT.AD  (W  :  in  WORD); 

-  used  to  insert  a  word  into  auxiiiary  dictionary 

procedure  INSERT.AD^UNUSED  (W :  in  Word); 

-  used  to  insert  a  word  into  the  unused  portion  of 
••  the  auxiiiary  dictionary 

end  AUX_DICT; 
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with  TEXT_OPS,  MAIN_DICT.  FAST_DICT,  AUX.DICT; 
use  TEXT_OPS,  MAIN.DICT,  FAST.DICT,  AUX_DICT; 

package  body  TEST_WORD  is 

-  from  TEXT.OPS  import  WORD.  UPPERCASE,  LENGTH. 

SPECIAL_ENDING_1,  SPECIAL_ENDING_2, 
SPECIAL_ENDING_3,  STRIP_ENDING_1 . 
STRIP_ENDING_2.  STRIP_ENDING_3, 

ING.ENDING,  ADD_E, 

REMOVE_APOSTROPHES 

-  from  MAIN_DICT  import  LOOKUP.MD 
--  from  FAST_DICT  import  LOOKUP_FD 

-  from  AUX^DICT  import  LOOKUP.AD,  INSERT_AD_UNUSED 

function  iDENTIFY_WORD  (W  :  WORD)  return  booiean  is 
TEMP^WORD ;  WORD; 

I  :  integer; 

function  ISJN_DICTIONARIES  (W  :  WORD)  return  boolean  is 
begin 

if  (Length(W)  <-  6)  and  then  LOOKUP.FD  (W)  then 
return  True; 

elsif  LOOKUP.AD  (W)  then 
return  True; 

elsif  LOOKUP  MD  (W)  then 
INSERT_AD1uNUSED  (W); 
return  True; 
else 

return  false; 
end  if; 

end  ISJN.biCTIONARIES; 

begin  -IDENTIFY_WORD 

W UPPERCASE  (W); 

-  remove  apostrophe  if  it  is  first  or  last  symbol 
REMOVE_APOSTROPHES  (W); 

If  SPECIAL_ENDING_1  (W)  then 
TEMP.WORD  STRIP_ENDING_1  (W); 
if  ISJN.DICTIONARIES  (TEMP_WORD)  then 
return  true; 
end  if; 

elsif  SPECIAL.ENDING  2  (W)  then 
TEMP_WORD  STRIP_ENDING_2  (W); 

If  ISJN.DICTIONARIES  (TEMP_WORD)  then 
return  true; 
end  if; 
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elsif  SPECIAL  EN0ING.3  (W)  than 
TEMP  WORD  STRIP  ENDINQ.3  (W); 
if  IS JN.DICTIONARtES  (TEMP.WORD)  then 
return  true; 
end  if  ; 

If  ING  ENDING  (W)  then 
TEMP  WORD  ADD_E  (W); 
if  IS.IN.DICTIONARiES  (TB4P_WORD)  then 
return  true; 
end  if; 
ertd  if; 
end  if; 

if  ISJN.DICTIONARIES  (W)  then 
return  True; 
eise 

return  Raise; 
end  if; 

end  IDENTiFY.WORD; 
end  TEST.WORD; 
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with  TEXT_OPS.  COUNTERS.  TEST  WORD.  MAIN  DICT,  FAST_DICT. 
AUX.DICT. 

TEXT  K).  DISK^IO; 

use  TEXT  OPS.  COUNTERS,  TEST_WORD,  MAIN_DICT,  FAST^DICT, 
AUX^DICT, 

TEXT_IO.  DISK.IO; 

procedure  SPELL  is 

-  from  COUNTERS  import  INCREMENT  arKi  DISPLAY 

-  from  TEXT_OPS  Import  LINE,  WORD,  GET_LINE,  QET^NEXT.WORD, 

END  OFFLINE.  LONQ.WORD,  INPUT, 
get” INPUT.TEXT,  create_output_text, 
PUT_OUTPUT,  AND  WORD  HANDLER 

-  from  TEST.WORD  import  IDENTIFY  WORD 

••  from  MAIN^DiCT  import  NUM.FOUND.MD  and  CLOSE.MD 
••  from  FAST  DICT  import  NUM_FOUND_FD  and  CLOSE.FD 

-  from  AUX3iCT  import  NUM_FOUND_AD  and  CLOSE.AD 

-  from  Text_io  import  put.  get.  new_iine,  and  putjine 

-  from  Diak_io  import  end.ofJUe 

package  INTJO  is  new  Integer  JO  (integer); 
use  INTJO; 

INPUT  LINE  :  LINE; 

A_WORD  :  WORD; 

NAME  :  String  (1.. 20); 

LINE.COUNT, 

WORD_COUNT  :  COUNTER; 

procure  INFORMATION; 
begin 

put  ("What  is  the  name  of  the  text  to  be  checked?"); 
newjine; 

put  ("Your  must  use  the  '.TEXT  suffix  > "); 
get  (Name); 

GETJNPUT_TEXT  (NAME); 
newjine  (3); 

put  CYVhat  is  the  name  of  the  new  text?"); 
newjine; 

put  ("You  must  use  the  '.TEXT  suffix  > "); 
get  (NAME); 

CREATE_OUTPUT  TEXT  (NAME); 
end  INFORMATION; 


begin 


INITIALIZE  (LINE.COUNT); 
INITIALIZE  (WORD_COUNT); 
INFORMATION; 
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INPUT.UNE GETJLME; 

•xit  whMi  ENOJOF.LINE  (INPUfT); 
INCREMENT  (LINE.COUNT); 
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loop 


A_WORD GET_NE)CT_WORD  (INPUT.LINE); 
exit  when  END_OF_LINE; 
if  not  LONG_WORD  then 
INCREMENT  (WORD_COUNT); 
if  not  IDENTIFY  WORD  (A.WORD)  then 
put  (ASCII.BEL); 

WORD.HANDLER  (A  WORD,  INPUT_LINE, 

WORD.COUNT, 


LINE.COUNT); 


end  if; 
end  if; 
end  loop; 

PUT^OUTPUT  (INPUT_UNE); 
end  loop; 
newjine  (3); 

put  (The  number  of  lines  processed  is "); 

DISPLAY  (LINE.COUNT); 
newjine; 

put  (The  number  of  words  processed  is  ”); 

DISPLAY  (WORD_COUNT); 
newjine; 

put  (The  number  of  words  found  in  main  dictionary;  ”); 

putjine  (NUM_FOUND_MD); 

newjine; 

put  (The  number  of  words  found  in  fast  dictionary: "); 

putjine  (NUM_FOUND_FD); 

newjine; 

put  (The  number  of  words  found  in  auxiliary  dictionary: "); 
putjine  (NUM_FOUND_AD); 
newjine; 
end  SPELL; 
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1.  Requirernwits  as  an  end  product  and  the  standards  applied  to  them. 

2.  The  requirements  deveio^ent  process. 

3.  Requirements  validation. 


ij  wii :  liiH  <  =5  j 


1 .  Use  several  techniques  to  extract  requirements. 

2.  Understand  several  methods  of  requirements  specification. 

3.  Follow  the  steps  in  a  requirements  standard  such  as  2167a. 

4.  Develop  a  requirements  validation  plan. 

SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

As  you  recall  we  have  dismissed  several  techniques  for  identifying 
requirements.  Once  the  requirements  are  identified  there  are  still  several 
major  tasks  which  have  to  be  accomplished. 

(Learning  Label-  Today  we  are  going  to  ieam  ...) 

T^ay  we  are  going  to  Ieam  about  the  elements  that  make  up  the  remaining 
stages  of  the  requirements  process  and  how  they  relate  to  a  requirements 
document.  We  will  discuss  the  elements  of  a  requirements  document  and 
the  steps  in  the  process  of  developing  the  document. 

CONTENTS: 

1.  Ask  the  students  to  recall  the  3  primary  goals  of  a  requirements 
document. 

a.  To  establish  agreement  about  a  system  between  the  sponsors, 
users  and  developers  of  a  system. 

b.  To  function  as  a  transition  from  the  problem  space  into  the 
solution  space  by  being  the  basis  for  software  design. 

c.  To  support  the  verificatton  and  validation  of  the  system. 

2.  The  development  of  requirements  is  quite  difficult  and  several 
organizations  have  formulated  complete  software  development 
methodologies  which  include  a  discussion  of  requirements. 

a.  Requirements  definition:  as  the  process  of  determining 
requirements  tor  a  system.  The  software  development  process 
has  been  formalized  by  a  number  of  organizations.  Private 
Companies,  NASA,  DoD.  We  will  look  at  one  of  those 
standards  DoD_STD  2167A. 

i  Software  requirements  are  distinguished  from  system 
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requiremente  when  the  software  requirements  are  part 
of  a  larger  system. 

L170H1 

ii  Discuss  the  document  structure  endorsed  by  21 67a.  The 
relation  is  systems  contain  segments,  segments  contain 
configuration  items,  configuration  items  contain 
configuration  components(CSCs)  and  components 
contain  units(CSUs). 

iii  This  standard  treats  software  development  as  a 
milestone-driven  project.  Milestones  are  generally 
documents  or  clearly  specified  events.  2167a 
characterizes  several  processes  separated  by  the 
completion  of  milestones.  L170H2 

Point  out  the  reviews.  Work  through  the  chart  showing 
the  relation  to  what  steps  they  have  experienced  in  the 
small  project. 

b.  Briefly  discuss  functional  requirements  and  tasks  to  be 
accomplished.  Functional  requirements  are  the  external 
behavior(the  functions)  expected  by  the  user  of  the  system. 
These  tasks  must  be  dearly  stated  in  a  precise  manner  so  that 
they  can  be  tested.  For  example  a  functional  requirement  of 
the  KoFF  system  would  be  dispense  tapes. 

c.  Discuss  non-functional  requirements  in  terms  of  restrictions  or 
constraints  on  the  system.  These  are  elements  which  the 
customer  lives  vwth  all  the  time  and  so  they  are  the  hardest  to 
extract  from  him/her.  They  are  caused  by  hardware,  laws,  the 
environment,  oolitical  preferences.  Sometimes  these 
requirements  are  very  hard  to  gather.  Ask  the  students  why 
there  might  be  more  difficulty  gathering  these  requirements. 
(The  sort  of  answer  you  are  looking  for  includes  The  customer 
takes  their  environment  for  granted  and  presumes  that  you 
understand  the  constraint  of  their  system.)  For  example  -  the 
customer  forgot  to  tell  you  that  their  hardware  is  a  Commodore 
64  computer  with  64  K  RAM. 

i  Metrics  for  non-functional  requirements  include  speed, 
size,  ease  of  use,  reliability,  robustness,  portability 

ii  Review  the  Mynatt  list  on  pages  71  and  72  &  give 
examples. 

d.  Ask  the  students  about  non-functional  requirements  of  their 
small  projects.  [E.g.,  the  system  is  to  be  implemented  in 
Pascal,  the  KoFF  system  must  release  tapes  within  3  seconds 
of  selection.  Note  that  the  function  to  be  performed  -dispense 
tapes-  has  not  changed.)  Another  example  is  writing  a  system 
for  a  foreign  customer,  where  the  documentation  must  be  in 
their  language. 
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e.  Requirements  Specification  presents  the  details  of  the  system. 
Sometimes  this  is  divid^  into  high-level  requirements 
specification  which  talks  about  systems  details  and  software 
specification  which  is  a  document  addressed  to  system 
designers.  There  are  many  ways  to  express  these  details. 
Natural  language  has  several  ambiguities.  Sometimes  the 
same  requirements  get  listed  as  two  tasks  because  the 
developer  did  not  realize  it  was  the  same  task.  Formalism 
have  been  developed  to  try  to  reduce  ambiguity.  Examples  of 
such  formalism  are  formal-algebraic  specification  and  special 
languages  such  as  PSL/PSA  and  SADT. 


f.  Specifications  should  include  all  the  default  conditions  and  how 
to  handle  error  conditions.  Often  default  conditions  are 
forgotten  by  the  analyst  or  the  customer.  In  these  cases  when 
the  system  is  executed,  it  is  initialized  to  a  default  state  no  one 
considered,  which  could  be  unpredictable  and  or  dangerous. 
Because  the  analyst  is  not  completely  familiar  he/she  does  not 
know  how  error  conditions  should  be  handled.  All  error 
conditions  and  how  to  handle  them  should  be  specified  in  the 
requirements. 

g.  Requirements  validation  -  it  is  critical  to  get  the  requirements 
correct  because  any  mistake  made  here  will  cost  more  in  effort 
and  dollars  later  on..  There  are  many  standards  for 
requirements.  They  should  be  checked  for  consistency, 
correctness,  and  ^moleteness.  feasibility,  functionality, 
testability,  easy  to  change 

i  Formal  review  -  walk-throughs  and  inspections 

ii  Requirements  validation  matrix-compare  this  with  the 
requirements  traceability  matrix  used  in  the  sample  test 
plan  L9HD1 . 


There  are  several  distinct  tasks  which  must  be  accomplished  to 
develop  a  requirements  definition. 

a.  Remind  them  of  the  discussion  of  requirements  identification 
and  ask  them  to  describe  the  three  methods  of  requirements 
gathering  discussed  in  the  last  class. 

i  Context  analysis  as  a  method  of  identification  (from 
Ross)  which  asks  why  the  software  is  created,  what  is 
the  environment  of  the  software,  and  what  are  the 
operational,  economic  boundary  conditions  that 
acceptable  software  must  satisfy.  The  result  of  this  is 
called  software  needs. 

ii  Elicitation  of  requirements  related  information  from  end- 
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users,  subject  matter  experts  and  customers.  This  is 
both  a  fact  finding  and  validation  effort.  Fact  finding 
includes  interviews,  questionnaires,  and  observation  of 
the  environment.  Validation  involves  presenting 
documentation  of  the  results  to  the  customer  and 
resolving  open  issues. 

b.  There  are  several  other  inputs  to  the  process  of  requirements 
gathering. 

i  Using  system  requirements  such  as  those  associated 
with  embedded  software) 

ii  Developing  user  interface  requirements  (2167a  Interface 
Requirements  Specification  IRS) 

c.  Identification  of  software  development  constraints:  cost, 
hardware.fault  tolerance. 

d.  Requirements  analysis  involves  relating  all  of  the  requirements 
gathered  from  diverse  sources-  satisfy  the  customer 

i  Assessment  of  potential  problems  and  determination  of 
acceptable  risk 

ii  Classification  of  requirements  done  in  terms  of 
mandatory,  desirable,  and  inessential.  It  is  also  helpful 
to  classify  ^em  in  terms  of  stability-  which  ones  are 
likely  to  change.  Ask  them  how  this  knowledge  would 
effect  design.  They  should  isolate  requirements  that  are 
likely  to  change. 

iii  Consider  both  the  technicai(can  computers  do  it)  and 
operational(can  the  staff  use  the  system  in  our 
environment)  feasibility  of  the  system.  Also  consider  the 
economic  feasibility  of  the  s^em.  What  would  the 
student  think  of  devebping  a  checkbook  babndng 
program  which  required  input  using  reverse  polish 
notation  fcx’  a  computer  that  weighed  20  pounds  and 
cost  $350.00. 

e.  Requirements  representatbn-  a  step  of  requirements  definition 
whbh  portrays  the  results  of  requirements  identification. 

i  Use  of  models 

11  Prototyping  as  a  means  of  clarifying  the  requirements 

f.  Requirements  communbatbn  involves  presenting  the 
requirements  to  diverse  audiences  for  review  and  approval 

g.  Requirements  validation 

i  Show  2167a  requirements  summary  evaluation  criteria 

and  go  over  them.  LI  70H3 

ii  Show  2167a  figure  5  and  review  the  items  L170H4 
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Traceability  to  system  specification  and  statement 
of  work.  Consistency  with  IRS  and  other 
specifications  for  interfacing  items.  Testability  of 
requirements.  Adequacy  of  quality  factor 
requirements. 

Traceability  to  system  specification  and  statement 
of  work.  Consistency  with  other  specifications 
for  interfacing  items.  Testability  of  requirements. 

iii  Discuss  verification  and  validation(V&V)  as  a  separate 
process  and  then  show  and  discuss  the  V&V  standards 
for  requirements  analysis.  L170H5 

iv  Establishment  of  acceptance  criteria 

iv  Tie  this  to  development  organizations  which  is  the 
subject  of  the  next  class.  Some  methods  of  organizing 
sof^are  development  teams  improve  the  quality  of  the 
validation. 


PROCEDURE: 

teaching  method  and  media: 

The  class  was  primarily  lecture  with  some  discussion. 
vocabulary  introduced: 


2167a 

Requirements  validation  plan 
Computer  software  configuration  item  (CSCI) 
Computer  software  components  (CSC) 
Computer  software  units  (CSU) 

Hardware  configuration  items  (HWCI) 
Interface  requirements  specifications  (IRS) 


INSTRUCTIONAL  MATERIALS: 


O-YfiEllfiads: 

L170H1 

L170H2 

L170H3 

L170H4 

L170H5 


The  language  of  Standard  2167A 
Deliverable  products 

Requirements  summary  evaluation  criteria 
Software  requirements  analysis 

Verification  and  validation  standards  for  requirements  analysis 


handouts: 
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(tabs  and  exerctaes) 

Lab  015  >  Initial  user  perspective  of  extended  project 

READING  ASSIGNMENTS: 

Sommerville  Chapter  3  (pp.  45-61) 

Sommerville  Chapter  5  (pp.  85-91) 

Mynatt  Chapter  2  (pp.  62-91) 

RELATED  READINGS: 

Qhezzi  Chapter  5  (pp.  151-160) 

John  Brackett,  Software  Requirements.  SEi-CM-19-1.2.  January  1990. 
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DOD-STD-2167A 

Exampte  of  System  Bisakdown  and 
CSCI  Decompositfon 


L170H1 


moNcn 


Requirements  Evaluation  Criteria 


Criterion 

Attributes 

Language 

a  Concise,  quantitative 
requirements 

a  Proper  use  of  Shail  and  Will 

Consistency 

a  Standardized  format 
a  Technical  consistency 
a  Uniform  level  of  detail 

Compieteness 

a  Acceptable  technical  level 
a  Timing,  accuracy  requirements 
stated 

a  Capacities  specified 
a  Terms  and  acronyms  defined 

Lack  of 
ambiguity 

a  Clear  organization 
a  Firmness  of  requirements 
a  Clear  functional  traces  possible 
a  Requirements  not  open  to 
interpretation 

Necessity 

a  Requirements  needed  to  fulfill 
system  objectives 
a  Requirements  not  superfluous 

Testabiiity 

a  All  the  above  criteria  satisfied 

a  Capability  to  develop  physical 

and  functional  tests 
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Ewiliwlion  Crit«ria  for  Prodii^  of 
Soflwato  ffoyiiiomonfo  Anolyifo 


Internal  Consistency 
Understandability 

Traceability  to  the  indicated  docunrants 

Consistency  with  the  indicated  documents 

Appropriate  analysis,  design,  or  coding 
techiques  used 

Appropriate  allocation  of  sizing  and  timing 
resources 

Adequate  test  coverage  of  requirements 
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Software  Requirements  Analysis 
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1.  Team  organizations  and  softwm  quality. 

2.  Roles  and  responsibilities  in  a  matrix  organization. 


INSTRUCUQMAL  QBJEgHVaS): 

1.  Understand  different  project  team  organizations  and  their  impact  on 
quality. 

2.  Understand  the  variety  of  roles  in  sofhvare  development. 

SET  UP.  WARM-UP: 

(How  to  involve  learner:  recall,  review,  relate) 

Most  software  projects  today  are  too  large  to  be  completed  by  a  single 
individual.  Several  people  have  to  work  together  in  completing  individual 
tasks  which  contribute  to  the  final  software  product,  and  several  groups  of 
people  have  to  work  together  organizing  the  components  which  constitute  the 
final  complex  software  artifact.  The  structure,  effective  organization,  arnl 
management  of  these  teams  has  a  direct  impact  on  the  quality  and  timeliness 
of  the  final  software  product. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  are  going  to  look  at  different  types  of  organizations  and  their 
impact  on  quality. 


COMTEHIS: 

1 .  Team  organization-  Software  development  like  any  management  effort 
must  organize  people  so  that  they  can  effectively  accomplish  their 
goals.  The  structure  of  the  team  is  dictated  by  Hs  goals.  Discuss  how 
sports  teams  are  organized.  Each  member  of  a  team  has  a  specific 
role  and  has  particular  constraints  placed  on  him/her.  The  third 
baseman  is  encouraged  to  handle  the  ball  when  it  is  hit  or  thrown  to 
him/her.  However  the  third  baseman  is  prohibited  from  pitching  the 
ball. 

2.  Teams  can  be  organized  based  on  control  or  function. 

a.  We  characterize  team  organization  based  on  where  decision 
making  control  resides.  A  team  can  have  centralized  control 
where  a  recognized  leader  is  responsible  for  all  final  decisions 
and  to  resolve  all  technical  issues.  One  such  model  is  called 
a  chief  programmer  team.  A  team  organization  can  also  be 
based  on  a  distributed  model  of  control,  emphasizing  group 
consensus.  This  is  illustrated  in  a  democratic  team 
organization.  There  can  also  be  hybrid  combination  of  these 
two  types  of  control. 
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b.  We  can  also  define  an  organization  in  terms  of  its  functions. 
Large  organizations  have  a  control  structure  which  ia  tied  to 
the  major  functions  of  the  organization.  For  example  consider 
an  organization  whose  primary  goal  is  sales.  It  will  have 
departments  for  marketing  sales  and  publicity  but  not  for 
manufacturing.  The  primary  decision  making  responsibility  will 
be  distributed  to  each  of  these  departments. 


3.  Four  basic  organizational  structures  that  have  been  used  to  model 
teams  after  are: 


a.  An  application  organization  is  a  traditional  hierarchical 
organization  with  clearly  visible  product  objectives.  The  chain 
of  command  and  control  is  vertical.  This  structure  has  the 
advantages  of  isolating  the  lower  levels  from  higher  level 
decisions. 

b.  A  functional  organization  is  organized  around  technical  skills  of 
expertise.  A  system  testing  group  or  an  analysis  group 
represent  a  functional  unit  in  a  functional  organization. 
Function  groups,  like  application  groups,  normally  work  on 
many  projects.  This  is  a  service  oriented  structure  rather  than 
a  product  oriented  structure.  This  has  the  problem  that 
because  a  manager  directs  several  projects,  which  project  is 
only  a  part  time  effort.  Reporting  in  this  group  is  not  to  the 
project  manager  directing  the  project  but  to  the  functional  group 
manager. 

c.  A  project  organization  is  a  single  group  formed  to  carry  out  a 
single  long  term  project.  Because  this  group  is  dedicated  to  a 
single  project  it  has  significant  visibility. 

d.  A  matrix  organization  is  organized  on  two  axes  --  one  being 
skill  groups  and  the  other  being  projects.  The  vertical  axes 
consists  of  grouf^  such  as  test,  code,  requirements,  etc.  While 
the  horizontal  axes  consists  of  the  projects  currently  under 
review  or  in  progress.  This  model  enables  the  allocation  of 
human  resource  to  multiple  projects.  This  is  useful  for 
temporary  or  short  lived  projects.  Personal  who  are  already 
familiar  with  the  environment  will  get  assigned  to  the  project. 
However  this  type  of  organization  does  not  foster  devotion  to 
an  individual  project. 

L180H2 

4.  Several  software  team  organizations  can  be  used  within  these 
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business  organization. 

a.  The  democratic  team  in  which  there  are  no  predetermined  lines 
of  communication  is  a  common  model  of  team.  This  is 
essential  the  model  followed  on  your  first  project.  Ask  the 
students  what  problems  exist  for  this  type  of  team.  You  are 
looking  for  things  like:  no  dear  dedsion  maker  and  so  work  had 
to  be  redone  and  significant  difficulty  in  communication.  For 
each  additional  team  member,  we  reduce  the  communications 
capability.  The  total  number  of  lines  of  communication  in  this 
type  of  team  is  N(N-1)/2. 


b.  The  chief  programmer  model,  sometimes  called  the  surgical 
model  established  very  clearly  defined  roles  and  threads  of 
control.  The  team  is  made  up  of  about  six  programming 
support  personnel,  one  of  who  is  the  backup  for  or  assistant  to 
the  chief  programmer  who  could  replace  the  chief  programmer 
if  necessary.  The  chief  programmer  designs  and  implements 
the  critical  parts  of  the  software.  The  other  members  of  the 
team  consist  of  an  administrator  who  takes  care  of  the  day  to 
day  non-programming  details;  a  librarian  who  maintains  all  the 
program  listings  and  can  function  as  project  configuration 
manager.  The  team  will  also  have  a  toolsmith  or  language 
specialist  who  cal  take  can  of  critical  language  decisions.  In 
this  model  communication  is  minimized  through  the 
administrator.  If  a  new  programmer  is  added  then  there  is  only 
one  new  line  of  cx^mmunication  to  the  administrator. 

c.  There  are  hybrids  of  these  two  teams  which  minimize 
communication  using  a  surgical  model  and  then  open  the  lines 
of  communication  at  the  more  technical  level  using  the 
democratic  model. 


Assessment  of  team  organization 

a.  Different  teams  are  appropriate  to  different  projects,  no  one 
team  organization  is  appropriate  for  all  tasks. 

i.  decentralized  control  works  well  when  communication  at 
a  low  level  is  needed  to  achieve  the  goal. 

ii.  centralized  control  works  well  when  the  problem  is  well- 
understood  and  rapid  development  is  important. 

b.  Discuss  the  advantages  and  disadvantages  of  each  type  of 
team  organization. 
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PROCEPURE: 

tettchino  mrthod  and  madia: 


YQcabutaTY  intmdufiftd: 

functional  organization 
chief'programmer  team 
centralize  control 
democratic  team 
matrix  organization 

INSTRUCTIONAL  MATERIALS: 
overheads: 

L18OH01 

L18OH02 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  016-  Immediate  tasks  for  configuration  management, 
requirements,  user  interface,  and  test  plan  teams. 

READING  ASSIGNMENTS: 

Mynatt  Chapter  1  (pp.  31-42) 


RELATED  REAPINGS: 

Ghezzi  Chapter  8  (pp.  440-446) 
Schach  Chapter  1 1  (pp.  357-368) 
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urganizanons 

Team  Management  Goals: 

Clear  assignment  of  responsibility 

I 

Facilitate  cooperation  for  common  goals 
effective  size 
clear  leadership  structure 

i 

I 

Control  based  organization 
Centralized  control 
Distributed  control 
Hybrid  forms  of  control 


Functional  Based  organization 
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Teams  and  Risks 

Software  Orgnaizations; 

Organizational 

Functional 

Software  Teams 
Democratic  Team 

Surgical/Chief  Programmer  Team 

Hybrid  Team 
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TPPIC(S)  FOR  LSCTURE: 

Moving  from  entity  relationshtp  diagrams  (ERDs)  to  Ada 


INSTRUCTIONAL  OBJECTiVEfS): 


1 .  Understand  the  concepts  and  notations  of  ERDs 

2.  To  learn  how  to  use  ERDs  to  derive  objects  and  operations  to  form  an 
Ada  specification. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

In  a  recent  class,  you  were  introduced  to  ERDs  as  an  analysis  notation  for 
understanding  the  problem  domain  during  structured  development.  These 
ERDs  can  also  be  used  to  assist  in  deriving  the  objects  and  operations  for 
a  problem  domain. 


(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  will  look  at  using  ERDs  to  derive  objects  and  operations. 


CONTENTS: 


1 .  Entity  relationship  diagram  (ERD) 

a.  An  ERD  graphically  depicts  the  static  nature  of  the  msyor 
entities  of  the  system  and  their  respective  interrelationships. 
An  ERD  can  be  derived  from  an  event  list.  An  event  list  is  a 
list  of  the  system's  actions  which  affect  the  system's 
processing.  This  list  can  be  stated  in  a  standard  sentence 
format  with  a  subject,  verb,  and  direct  ot^.  An  ERD  can  be 
derived  from  an  event  list  by  defining  the  subjects  and  direct 
objects  as  entities  and  the  verbs  as  relationships  between  the 
entities.  An  entity  is  some  individual  item  of  interest  in  the 
problem  domain.  An  ERD  is  a  network  which  depicts  how 
entities  of  the  system  are  interrelated. 

b.  ERDs  are  well  known  and  understood  and  provide  a  good 
starting  point  for  the  derivation  of  objects  and  operations  in  a 
problem  domain.  The  derivation  of  objects  and  operations  in 
a  problem  domain  is  not  a  well  understood  process,  as  of  yet. 
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ERDs  provide  a  static  view  of  a  system  which  cart  be  used  as 
a  buiiding  block  for  the  data  abstraction  of  object-oriented 
design.  The  usefulness  of  the  ERD  is  that  it  provides  a  frame 
of  reference  fbr  identifying  the  objects  of  the  ot^ect-oriented 
design. 


2.  Entity  categories 

a.  The  entities  from  the  ERD  provide  a  starting  place  fbr 
determining  the  objects  of  a  system;  however,  not  all  entities 
from  the  ERD  will  become  objects  in  the  final  design.  The 
entities  are  first  categorized  before  determining  which  entities 
become  objects  in  the  design. 

b.  The  following  entity  categories  have  been  identified  as  common 
types  of  entities  which  exist  for  a  system: 

i  External  entities  are  the  terminators  on  the  context 
diagram  which  do  not  "own”  any  data  in  the  problem 
domain.  These  entities  do  not  require  data  definition 
within  the  scope  of  the  system. 

ii  internal  entities  are  the  terminators  on  the  context 
diagram  which  do  "own”  data  in  the  problem  domain. 
These  entities  require  data  definitton  within  the  scope  of 
the  system. 

iii  User-view  entities  present  a  "view"  to  the  user. 
Examples  are  a  report  or  a  screen. 

iv  Dependent  entities  have  little  significance  to  the  system 
alone  and  must  be  associated  with  another  entity  for 
identification. 

V  Identifiable  entities  are  independent  system  elements. 


3.  Objects  and  operations  from  entities 

a.  Any  entities  which  are  derived  from  nonautomated  events  are 
eliminated  from  fijrther  consideration. 

b.  External  entities  and  dependent  entities  are  eliminated  from 
consideration  as  objects.  External  entities  are  excluded  from 
the  design  since  they  are  not  part  of  the  problem  domain. 
Dependent  entities  are  excluded  from  the  object  list  since  they 
are  represented  in  the  design  by  other  objects  upon  which  they 
are  dependent. 

c.  The  remaining  entities  provide  a  preliminary  list  of  ok^cts  for 
the  system. 
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d.  The  operations  which  remain  are  associated  with  the 
operations  specified  in  the  ERD.  The  DFDs  for  the  system 
may  help  to  i(tentify  operations  based  on  events  in  the  ERD. 

e.  Each  object  and  its  associated  operations  becomes  a 
subsystem  (i.e..  Ada  package  specification)  for  the  system. 
These  pactoge  specifications  wiii  be  competed  giving  the 
interface  for  each  operation. 


PRQCEPURE: 

teaching  method  and  media: 


vocabuiarv  introduced: 


INSTRUCTIONAL  MATERIALS: 
overheads: 

handouts: 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  017  -  Configuration  management  plan  presentation/review 

READING  ASSIGNMENTS: 
none 


RELAT^P  REAPINGS: 

Stoecklin,  Adams,  and  Smith,  "Object-oriented  Analysis"  at  Proceedings  of 
the  Fifth  Washington  Ada  Symposium.  June  1988,  Tysons  Corner, 
Virginia,  pp.  133-138. 
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LECTURE  NUMBER:  021 


TOPICfS^  FOR  LECTURE: 
Verification 
Validation 


INSTRUCTIONAL  OBJECTIVEfS^: 


1.  To  understand  the  roles  of  verification  and  validatioi  in  the  software 
lifecycle. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

In  previous  classes,  we  have  tafited  about  the  production  of  quafity  software 
being  a  major  concern  in  software  engineering.  A  necessary  approach  to 
achieve  quality  software  is  ttirough  the  use  of  verification  and  validation. 

(Learning  Label-  Today  we  are  going  to  leam  ...) 

Today  we  will  be  examining  verification  and  validation  in  detail. 


CONTENTS: 

1 .  Introduction  to  verification  and  validation  (V&V)  L210H1 

a.  Prior  to  the  use  of  verification  and  validation,  testing  was  the 
primary  means  of  ensuring  the  quality  of  software.  However, 
testing  was  performed  in  an  informal,  arbitrary  manner  usually 
by  the  programmer  working  in  isolation.  Testing  also  occurred 
only  at  the  end  of  development  after  implementation.  Quality 
products  are  developed  during  a  quality  process.  People  were 
trying  to  put  quality  into  the  software  AFTER  the  software  was 
developed.  They  were  trying  to  test  quality  into  the  software 
but  this  approach  was  not  working. 

b.  Verification  and  validation  are  process  for  ensuring  quality 
software  throughout  the  life  cycle  from  requirements  through 
maintenance.  V  and  V  are  complimentary,  yet  distinct.  The 
main  objectives  of  V  and  V  are  the  discovery  of  defects  in  any 
of  the  p^ucts  (requirements  documenL  de^  document,  etc) 
as  they  are  develop;  and  the  assessment  of  whether  or  not 
the  system  satisfies  the  specified  requirements.  This  process 
permeates  the  entire  life  cycle.  Errors  should  be  detected  as 
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early  in  the  development  cycle  as  possible. 

L210H2 

c.  Three  types  of  analysis  are  used  in  V&V.  Static  analysis 
involves  no  execution;  it  is  the  manual  or  automated 
examination  of  a  prc^uct  (e.g.,  software  requirements 
specification  document,  source  code).  Examples  of  static 
analysis  include  software  reviews  and  static  program  analyzers. 

Dynamic  analysis  involves  execution  of  software  where  the 
functional,  structural,  or  computational  aspects  of  the  software 
are  examined.  Examples  of  dynamic  analysis  include  unit  or 
module  testing  and  acceptance  testing. 

Formal  analysis  is  the  use  of  mathematical  techniques  to 
evaluate  a  product;  examples  of  formal  analysis  include 
symbolic  execution  and  proof  of  correctness. 


2.  Verification 
L210H3 

a.  Are  we  building  the  product  right?  Verification  involves 
evaluating  the  end  product  of  each  phase;  we  are  looking  for 
errors  generated  wi^in  the  phase  and/or  by  the  transformation 
between  phases.  The  product  is  evaluated  for  its  consistency, 
completeness,  and  correctness  according  to  the  previous 
phase.  This  is  done  during  each  phase  and  not  at  the  end  of 
the  life  cyde.  The  most  common  errors  occur  between  phases. 

b.  Although  the  product  is  the  primary  focus,  the  quality  of  the 
development  process  is  also  being  evaluated. 

c.  The  tasks  of  verification  are  to  assume  that  the  products  of 
each  software  life  cycle  phase: 

i  Comply  with  previous  life  cycle  phase  requirements  and 
products. 

ii  Satisfy  the  standards,  practices,  and  conventions  of  the 
phase,  and 

iii  Establish  the  proper  basis  for  initiating  the  next  life  cyde 
phase  activities. 

d.  Static  analysis,  dynamic  analysis  and  formal  analysis  are  used 
in  accomplishing  verification. 


3.  Validation  L210H4 
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Qualities  of  Coupling  Levels  (Page^ones) 


Coupling 

Type 

Suscepti¬ 
bility 
to  rip^e 
effect 

Modifia¬ 

bility 

Under- 

stand- 

ability 

Module's 
Usability 
in  other 
systems 

Data 

Variable* 

Good 

Good 

Good 

Tramp 

Poor 

Medium 

Medium 

Poor 

Stamp 

Variable* 

Medium 

Medium 

Medium 

Bundling 

Variable* 

Medium 

Poor 

Poor 

Controi 

Medium 

Poor" 

Poor" 

Poor" 

Hybrid 

Medium** 

Bad 

Bad 

Bad 

Common 

Bad 

Medium 

Bad 

Poor 

Content 

Bad 

Bad 

Bad 

Bad 

Depends  on  the  breadth  (the  number  of  individual  items) 
of  the  interface. 

Poor  mainly  because  of  concomitant  problems  in  the 
interface  and  the  cohesion  of  one  of  the  modules. 

If  the  convention  used  in  the  hybrid  data  has  to  be 
changed,  the  ripple  effect  can  be  devastating. 
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Prelminiry  dtsign  utkig  functional  daoompoiition 
Probtom  aoMng  paradgtnt 
Introduction  10  ob|acl-orlanl8lion 


INSTRUCTIONAL, QBifKTlYECS): 


1.  Understand  functionai  prelminary  design 

2.  Define  basic  concepts  of  object-orientation 

3.  Understand  an  object-oriented  approach  to  analysis 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

L260H1 

We  have  learned  the  basic  elements  of  design.  The  inputs  and  outputs  to 
the  design  process  have  been  defined  for  us.  One  of  our  authors  -Mynatt- 
describes  the  prelminary  design  process  and  includes  in  that  process 
interfboe  design  and  software  design.  She  and  others  have  described  design 
as  "basically  a  creative  process".  What  does  she  mean? 

(Learning  Label-  Today  we  are  going  to  learn ...) 

L260H2 

The  problem  with  prelminary  design  seems  to  arise  at  the  transitions  from 
analysis  to  an  architecture  and  from  an  architecture  to  a  documented 
solution.  Today  we  will  look  at  some  ways  to  make  those  transitions  easier 
and  concentrate  on  a  new  approach  called  object  orientation. 


CONTENTS: 

L260H3 

1.  Discuss  where  the  dHIculty  les  in  design.  Define  domain  analysis  as 
required  knowledge  of  the  system  environment.  Discuss  the 
dtfficuities  they  just  had  in  moving  from  data  flow  digrams  to  structure 
charts.  The  translation  process  between  the  problem  domain  and  the 
solution  domain  is  dHficuK  and  it  is  made  more  (fifficult  by  using 
different  notations  being  used  to  tal(  about  the  problem  domain  and 
the  sokition  domain.  For  example,  date  flow  dtegrams  for  the  problem 
space  and  structure  charts  for  the  solution  space,  domain. 

in  SA/SD  attention  shifts  from  analysis  to  design,  the  way  you  look  at 
the  problem  changes.  Although  there  are  techniques  to  help  move 
from  SA  to  SD.  this  shift  of  focus  makes  the  transition  more  difficult. 

L260H4 

2.  Discuss  how  object-oriented  design  is  intended  to  address  this 
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problem  by  providing  a  seamless  transition  between  development 
stages.  The  focus  of  object-oriented  design  is  on  the  things  in  the 
system  and  these  things  tend  to  be  more  stable  throughout  the 
development  process.  One  starts  with  a  set  of  objects  which  are  easily 
understood  in  the  analysis  stage.  Object-oriented  design  is  an 
elaboration  of  the  way  these  object  are  related  to  form  a  solution  to 
the  initial  problem..  The  details  of  the  design  get  embodied  into  the 
objects.  This  encapsulation  facilitates  maintenance  and  reusability. 

L260H5 

3.  Begin  an  illustration  of  object  oriented  development  by  giving 
preliminary  definitions  of  Objects.  Classes  and  Inheritance. 

4.  Spend  about  10  minutes  with  an  object  identification  exercise 
L260H6.  Brainstorm  with  the  students  about  the  objects  that  are 
needed.  The  objects  they  identify  will  include  bottle,  fill,  label,  wash, 
cap,  box,  ship  ....  List  the  objects  on  the  board  as  they  describe 
them.  Pause  to  show  them  that  they  have  outlined  a  system  mthout 
being  language  specific.  Discuss  some  of  these  candidate  objects, 
noting  that  some  of  them  are  both  nouns  and  verbs.  Label  is  an 
interesting  one.  A  label  has  data-the  type  of  beverage-,  it  also  has 
some  properties  -  glue  on  one  side-  which  enable  it  to  undergo  the 
Labeling  process.  Once  they  are  convinced  that  they  have  a  high 
level,  language  independent,  description  of  a  system,  develop  an  Ada 
package  called  LABEL  L260H7  to  show  them  how  an  object  can  be 
specified  in  Ada.  Use  the  package  to  explain  some  of  the  concepts 
of  reuse  and  encapsulation.  If  there  is  time  you  might  want  to  give 
a  high  level  treatment  of  generics  and  develop  a  generic  package 
called  FILL  which  is  passed  two  parameters,  the  size  of  the  bottle  to 
be  filled  and  the  type  of  beverage  to  be  placed  in  the  bottle. 
Exceptions  could  be  touched  on  here  as  the  error  conditions  for  this 
package,  e.g.,  overflow  of  bottle  and  not.completelyjill  the  bottle. 

L260H8 

4.  Discuss  Wenger's  distinction  between  Object-oriented  languages  and 
object-based  languages.  Because  Ada  does  not  currently  support 
inheritance  it  is  useful  to  spend  some  time  talking  about  the  virtues  of 
object-orientation  and  that  many  of  those  virtues  can  be  achieved 
independent  of  the  implementation  language.  Work  done  at  the 
NASA  software  engineering  lab  has  proven  that  the  use  of  an  object- 
oriented  methodology,  independent  of  the  language  environment  and 
the  availability  of  inheritance,  produces  significant  benefits.  Use 
L260H9  to  discuss  some  of  the  elements  of  object-orientation. 
Software  engineering  starts  with  real  world  non-computer  objects,  e.g., 
cars,  or  vending  machines.  These  objects  are  easily  identifiable  and 
are  more  than  just  functions  or  data.  Emphasize  the  black-box 
nature  of  these  objects.  They  present  and  external  interface  to  the 
work  and  restrict  access  to  their  internal  implementations.  In  Object- 
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orientation,  this  is  called  information  hiding  makes  non-essential 
information  inaccessible.  This  can  be  modeled  in  an  Ada  package. 
The  body  of  a  padtage  physically  encapsulates  both  data  and 
function. 

Talk  about  data  and  funchonal  abstraction  and  how  they  are  combined 
in  object-orientation.  Functional  abstraction  focuses  on  the  interface 
to  the  object,  but  is  does  not  know  how  the  function  is  accomplished 
within  the  object.  Using  a  vendor  supplied  sort  package  is  a  good 
example  of  this. 

inheritance  can  be  simply  modeled.  Tell  the  students  that  you  have 
a  Rumbo  outside.  When  they  ask  what  it  is,  tell  them  it  is  a  car. 
Point  out  that  now  they  can  tell  you  several  things,  both  attributes  and 
functions,  about  a  Rumbo  because  it  inherits  characteristics  from  the 
class  CAR.  This  is  a  good  point  to  use  a  sample  of  Rumbaugh 
notation.  Show  a  class  diagram  for  car  and  them  under  it  place  two 
other  class  diagrams  for  SEDAN  and  STATION  WAGON.  Draw  an 
inheritance  relation  between  these  three  showing  how  sedan  and 
station  wagon  inherit  all  of  the  characteristics  of  car.  Use  the  example 
of  the  car  and  return  to  the  concept  of  abstraction.  The  CAR  object 
can  be  presented  at  several  levels  of  abstraction.  A  high  level  of 
abstraction  views  a  CAR  as  an  object  which  transports  people.  At  a 
lower  level  we  can  talk  about  its  structure  or  the  interconnectedness 
of  its  part;  and  at  a  lower  level  we  can  talk  of  the  functions  of  its  parts. 
These  levels  of  abstraction  model  the  stages  of  object-oriented 
development  from  analysis  to  preliminary  design  to  detailed  design. 

L26OH10 

5.  Review  the  standard  problem  solving  paradigms  and  how  object- 
oriented  design  fits  in  with  these  paradigms.  The  choice  of  paradigm 
directs  the  entire  development  life  cycle.  Paying  attention  to 
paradigms  is  a  shift  in  focus  from  "Let's  see  how  I  can  solve  this 
problem  in  'C "  to  "What  design  technique  will  best  support  a  solution 
to  this  problem?" 


6.  Begin  a  discussion  of  domain  analysis  and  talk  about  the  different 
categories  of  objects,  viz.,  physical  objects,  roles,  incidents  like  airline 
flights,  and  interactions  between  objects  like  employee  works  for 
company.  How  these  object  are  related  in  object-oriented  design  will 
be  the  subject  of  the  next  lecture. 


2£££2UB£: 

teaching  method  and  media: 
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ot^ects 
encapsulation 
inheritance 
object-based 
object-oriented 
information  hiding 
procedural  abstraction 
data  abstraction 
fonctional  abstraction 


INSTRUCUQNAL  MAIERIALS: 


QYftfbfladg: 

L260H1 

L260H2 

L260H3 

L260H4 

L260H5 

L260H6 

L260H7 

L260H8 

L260H9 

L26OH10 

liaodfiuts: 


Design 

Preliminary  design  -  The  Transitions 
Preliminary  design  -  The  Transitions,  hissing  Elements 
Object-Oriented  Design 
Object  Orientation 

An  exercise  to  identify  some  ot^cts  in  a  problem  specification 
Ada  package  specification  for  Don's  Brewery 
Object-oriented  vs  object-based 
General  characteristics  of  object  orientation 
Object-oriented  development 


RELATED  LEARNING  ACTIVITiES: 

(labs  and  exercises) 

Lab  021  -  Preliminary  design 

REAPING  ASSIGNMENTS: 

Sommerville  Chapter  10  (pp.  182-188) 
Mynatt  Chapter  3  (pp.  94-130) 


RELATED  READINGS: 

Berzins  Chapter  4  (pp.  207-214) 
Booch  Chapter  5  (pp.  44-50) 
Booch(2)  Chapter  3  (pp.  34-41) 
Ghezzi  Chapter  4  (pp.  115-121) 
Pressman  Chapter  8  (pp.  239-282) 
Schach  Chapter  9  (pp.  282-284) 
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Design 


Preliminary  Design 

Input  Software  specifications 

Process  Generate  architecture  to  meet 

specifications 

Output  Preliminary  design  document 

Detaiied  Design 
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Preliminary  Design  -  The  Transitions 

Input  Problem  description  in  terms  of 
functions 

Determine  a  solution 

Process  Preliminary  solution  in  terms  of 
system  architecture,  might  inciude 
interface  design 

Record  a  solution 

Output  Preliminary  design  document 
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Preliminary  Design  -  The  Transitions 
Missing  Elements 


Input  Problem  description  in  terms  of  functions 

DOMAIN  ANALYSIS:  non>functional 
requirements,  understanding  of  the 
environment 

Determine  a  solution 

How  ?  •  "Basically  a  creative 
process",  "A  Flair" 

Process  Preliminary  solution  in  terms  of 
system  architecture,  might  include 
interface  design 

Record  a  solution 

What  method  of  notation  best  reflects 
both  the  problem  and  the  solution? 

Output  Preliminary  design  document 
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-Oriented  Design 


Goals  of  Object-Oriented  Design 


Avoid  transiation  probiem  between 
probiem  and  solution  statements. 


Estabiish  a  seamiess  transition  from 
design  to  impiementation. 


Make  programming  simpier,  more  iike 
reai-iife  (Aian  Kay-Smalltaik) 


Faciiitate  reuse  of  all  system  components. 

Make  all  forms  of  maintenance  easier  and 
more  reliable. 
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Object  Orientation 


Objects 


Classes 


Inheritance 


Real  world  entities  (SE)  or 
modules  with  constructor  and 
inspectors,  Ada  packages 
(Programmers) 

A  template  for  similar  objects 
or  instances 


A  class  acquires  the 
characteristics  from  one  or 
more  other  classes. 
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An  Exercise  to  Identify  Some  Objects  in  a 
Problem  SpMification 


Don  is  going  to  automate  one  aspect  of  his 
brewery.  He  wants  a  computerized  system  to 
controi  the  bottiing  of  the  beverages:  iager, 
aie,  stout,  and  bitters,  that  he  brews.  The 
retumabie  bottles  come  in  3  sizes:  one  pint, 
two  pints  and  three  pints. 
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Ada  Package  Specification  for  Don'a  Brewery 


with  TextJO; 
uses  TextJO; 
with  BOTTLE: 
uses  BOTTLE; 

Package  LABEL  is 

Procedure  GET_LABEL: 
Procedure  WET_LABEL: 
Procedure  PLACE_LABEL; 
end  LABEL; 

Package  body  LABEL  is 


Type 
Records 
Functions 
Procedures 
end  LABEL; 
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Object-Oriented  vs  Object-Based 


Peter  Wenger  1 986 

The  essential  elements  for  object  orientation 

1 .  Support  for  data  abstraction 

2.  Management  of  data  abstraction  by 
typing 

3.  Composition  of  abstract  data  types 
through  an  inheritance  mechanism 


The  benefits  of  object-orientation  have  been 
proven  to  be  dependent  on  the  adoption  of 
object-oriented  methodology  rather  than  on 
the  implementation  details"  Mike  Stark  - 
Software  Engineering  Laboratory 
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Infmrmatien  hkftig 


Abstraction 

Process 

Entity 

Leveis  of  abstraction 
Functional  and  data 

Encapsulation 

Inheritance 
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Problem  Solving  Paradigms 

Procedural 

Stream  of  actions 

Data  structures  are  passed 

State  of  system  maintained  globally 

Logical 

Access-Oriented 

Object-Oriented 

Problem  domain  objects 

Control  distributed  in  objects 

State  maintained  by  separate  objects 


Functional 


Change  of  orientation  from  coding  as  a  foundation 
for  a  solution  to  the  requirements  and  design  as  a 
foundation  for  a  solution 
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1.  HlQh  levsl  ofated-oritnltd  dMign 

2.  St^  in  praHminary  dMign 

3.  VaKdaling  praHminary  da^n 

4.  Notation  for  praHminafy  dMign 

INSTRUCTiONAL  QBJECTiVEfS^: 

1.  Undarstand  tha  ataps  in  praliminary  daaign  and  howto  taat  it 

2.  Davalop  a  praKminary  ofc^-oriantad  daaign. 

SET  URvWARM-UP: 

(How  invoive  laamer:  racaii,  raview,  raiata) 

in  our  previoua  diacuaaion.  wa  introducad  aonne  of  the  eiamanta  of  otiject* 
oriented  daveiopment. 

(Learning  Label-  Today  wa  are  going  to  learn  ...) 

L270H1 

One  can  uae  the  preliminary  producta  of  atructured  analyaia  to  aid  in  the 
development  of  object-oriented  deaign.  Today  we  ahail  examine  the 
components  of  an  object-oriented  design  and  look  at  the  detail  of  a 
preliminary  object-oriented  design. 

QSMISmS:. 

L270H2 

1 .  Review  basic  object-oriented  concepts,  especially  message  passing 
and  encapsulation  since  this  will  g^  connected  with  Ada  later  on. 
Illustrate  these  using  examples  consistent  with  the  KoFF  system. 
Examples  of  object  classes  include  a  video-tape  and  a  VCR.  The 
particular  instances  could  be  a  particular  video  tape  and  your  VCR. 
Message  passing  can  be  illustrated  by :  pushing  the  display  button  on 
the  VCR  or  the  end  of  tape  message  on  the  particular  video  tape 
which  sends  a  message  to  the  VCR  activating  a  number  of  processes. 
The  VCR  is  a  good  model  for  explaining  encapsulation  in  so  far  as  we 
do  not  know  the  internal  workings  of  the  VCR  activated  by  the  PAUSE 
or  DISPLAY  buttons,  inheritance  is  illustrated  by  talking  about  the 
classification  of  the  video  tape  movies.  Each  movie  has  many 
characteristics  in  common  with  other  movies  but  they  are  separated 
by  classification  into  'G',  'PG',  etc.  This  is  modeled  in  a  class 
hierarchy.  For  example  we  could  have  a  superclass  tape,  and  each 
subclass  type  of  type  -*G',  'PG',  etc  -  inherits  characteristics  from  the 
super  class.  Each  tape  coukf  also  be  considered  s  an  aggregate  of 
2  take  up  reels,  one  tape,  and  one  case. 

L270H3 


1 


Lecture  027 


Give  an  overview  of  both  preliminary  and  detailed  design.  Be  sure  to 
revisit  the  concept  of  domain  analysis  and  other  information  gathering 
techniques.  Discuss  class  design  as  a  method  to  decompose  a 
system  into  sub-systems  and  how  this  can  be  done  in  terms  of 
external  system  responsibilities  during  preliminary  design.  The 
students  might  find  this  easier  to  understand  if  you  talk  in  terms  of 
architectural  responsibilities.  The  interfaces  that  are  considered  at  this 
stage  are  related  to  the  external  behavior  required  by  the  user  to 
access  the  system.  Design  validation  is  an  important  concept  to 
reinforce.  The  input  documents  such  as  event  lists,  use  cases  or 
functional  requirements  lists  can  be  traced  to  see  that  the  design 
meets  all  of  the  system  requirements.  Briefly  discuss  the  outputs  of 
preliminary  design  with  an  emphasis  on  the  traceability  matrix  and  the 
information  from  preliminary  design  passed  to  detailed  design.  Show 
the  detailed  design  slide  very  briefly.  Emphasize  that  this  is  where 
implementation  details  begin  to  appear.  L270H4 


After  the  overview  of  design,  begin  a  detailed  discussion  of  object 
identification,  as  the  first  step  in  preliminary  design.  L270H5  indicates 
the  different  kinds  of  things  that  are  candidates  for  objects  for  a 
system. 

Ask  the  students  to  think  of  systems  where  each  of  these  might  be  an 
object.  You  might  also  use  the  KoFF  system,  a  garage  door  opener, 
or  a  spell  checker.  Othem  have  used  ATM  systems,  motor  vehicle 
registration  systems  ,  and  air  traffic  control  systems.  The  goal  is  to 
get  them  to  think  of  system  objects  as  including  more  than  tangible 
things. 

L270H6 

a.  Discuss  various  object  identification  techniques. 

i  Be  sure  to  admit  the  limitations  of  the  noun 
identification  technique.  Show  the  KoFF  system 
L270H7  description  and  start  to  list  the  nouns  in 
it.  L270H8  Then  show  a  partial  noun  list  and 
ask  them  to  identify  synonyms,  e.g,  membership 
card  and  movie  rental  card.  Have  them  remove 
the  synonyms.  Tell  them  that  objects  have 
attributes,  and  one  simple  way  to  identify 
attributes  of  objects  is  to  look  for  things  that 
cannot  exist  independently  but  must  be  properties 
of  something  else.  For  example,  color  cannot 
exit  alone  but  must  be  the  property  of  some 
object.  Similarly,  in  the  KoFF  system,  Price 
would  be  an  attribute  of  a  TAPE.  Look  at  the  list 
agsUn  for  nouns  which  are  attribute  candidates, 
e.g.,  due-date  must  be  the  property  of  some 
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object.  Then  have  them  group  some  the  nouns 
into  major  categories,  such  as  billings,  member, 
and  tapes.  These  categories  include  most  of  the 
nouns  which  can  be  potential  objects  or  can  be 
major  partitions  of  the  design. 

ii  Discuss  use  cases  as  another  identification 
technique.  L27OH10  Conversations  with  the 
customer  generate  descriptions  of  external 
system  behavior  which  can  be  modeled  in  mini¬ 
scenarios,  called  use  cases.  These  scenarios 
might  reveal  some  additional  system  objects. 
(This  is  a  recent  technique  developed  by 
Jacobsen). 

b.  Return  to  the  Object  identification  slide  and  discuss  a 
method  for  identifying  objects  behavior  which  is  based 
on  finding  verbs  which  indicate  an  objects  responsibility. 
L270H6  L270H9  Use  the  KoFF  system  description 
and  look  for  verbs,  associating  each  verb  with  some 
object  identified  in  the  noun  identification  pass.  These 
verbs  are  candidates  for  object  operations.  Sometimes 
operations  have  characteristics,  such  as  time 
constraints,  or  the  number  of  times  they  can  be 
repeated.  These  constraints  can  be  indicated  by 
adverbs.  Examine  each  object  in  the  list  for  relevancy. 
Remove  synonymous  objects  and  objects  which  are  not 
directly  related  to  the  system.  Remove  nouns  which 
cannot  exist  independently. 


4.  Present  the  Rumbaugh  object-model  notation  as  a  way  to  describe  the 
objects  that  have  been  identified.  Go  over  the  notation.  Be  sure  to 
discuss:  multiplicity,  association,  generalization  and  specialization,  and 
subclass  and  superclass.  It  is  helpful  to  use  examples  from  their  small 
projects  here.  L270H11  L270H12  L270H13  For  example, 
aggregation  can  be  illustrated  by  talking  about  a  vending  machine 
consisting  of  slots  and  a  change  maker.  A  video  tape  can  also  be 
considered  an  aggregate  of:  the  tape,  two  take  up  reels,  and  the  case. 

Derived  attributes  can  be  illustrated  with  KoFF  tape  due  date,  since 
it  is  a  function  of  the  rental  duration  and  the  initial  rental  date. 

L270H14 

5.  Clearly  discuss  the  deliverables  required  for  the  preliminary  design  for 
the  extended  project.  An  object  model  consisting  of  an  object  diagram 
using  Rumbaugh's  notation  is  required.  They  use  OMTool  for  this. 
The  object  model  also  includes  an  object  dictionary  and  a  traceability 
matrix.  The  importance  of  the  object  traceability  matrix  for  testing  and 
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further  development  is  emphasized.  They  are  also  expected  to  do 
Ada  specifications  for  each  ot^  as  an  interface  description.  The 
preliminary  design  team  should  also  develop  all  user  intertaces,  e.g., 
design  major  menus  for  the  system.  (If  you  have  a  user  interface 
team,  instead  of  a  user  manual  team,  then  the  design  of  menus 
belongs  to  the  user  interface  team) 

L270H15,  L270H16 

6.  The  Ciass  dictionary  provide  significant  information  needed  for  design 
and  implementation..  The  developer  can  use  this  dictionary  to  cross 
check  the  attributes  of  this  class.  The  specification  of  the  information 
needed  from  other  objects  heips  in  the  interface  design.  The  object 
traceability  matrix  is  used  to  verify  that  every  requirement  is  accounted 
for  in  the  object  design. 

PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 

traceability  matrix 

object  class 

instance 

encapsulation 

message 

method 

inheritance 

class  hierarchy 

object  model  notation 

class  dictionary 

subclass 

generalization 

specialization 


INSTRUCTIONAL  MATERIALS: 
overheads: 

L270H1 

Outline 

L270H2 

Definitions 

L270H3 

Object-oriented  design  (1) 

L270H4 

Object-oriented  design  (2) 

L270H5 

Identification  of  objects 

L270H6 

Object  identification  techniques 

L270H7 

KoFF  Automated  Video  Rental  System  description 

L270H8 

A  KoFF  partial  noun  list 

L270H9 

A  KoFF  partial  noun  and  verb  list 

L27OH10 

KoFF  use  cases 
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L270H1 1  Examptos  of  Rumbaugh  object-orientad  design  notation 
L270H12  More  examples  of  Runr^iaugh  object-oriented  notation 
L270H13  Object  model  notation  based  on  Rumbaugh  et  al. 
L270H14  Preliminary  design  deHverables 

L270H15  Example  layout  of  class  dictionary 

L270H1 6  Example  object  traceability  matrix  entry 

handouts: 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  022  -  Ada  laboratory  environment 

READING, ASSIGNMENTS: 

Mynatt  Chapter  8  (pp.  364-368) 

Sommerviile  Chapter  10  (pp.  177-182) 

Sommerviile  Chapter  11  {pp.  194-236) 

RELATED  READINGS: 

Qhezzi  Chapter  4  (pp.  115-122) 

Pressman  Chapter  12  (pp.  395-418) 

Ivor  Jacobson.Oblect-Oriented  Software  Enoineerino.  ACM  Press 
James  Rumbaugh,  et.al,  Object-Oriented  Modelinq  and  Desion.  Prentice  Hall 
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OUTLINE 


Definitions 


Design 

High  Level  Design  (Preliminary 
Design) 

Low  Level  Design  (Detailed  Design) 


Steps  in  High  Level  Design 


Notation  to  Express  the  High  Level 
Design  Model 


Preliminary  Design  Deliverables 


6 


L270H1 


Definitions 


OBJECT  CLASS  Models  "things"  in  the  world: 

the  model  has  attributes, 
operations,  and  a  precise 
interface  that  receive 
messages.  ( a  factory  waiting 
to  create  instances) 


INSTANCE  An  actual  object  waiting  to 

perform  services  and  having 
state,  (the  object) 


ENCAPSULATION  An  object's  state  data  cannot 

be  directly  accessed,  it  can 
oniy  be  asked  for  a  service. 


MESSAGE  The  oniy  way  objects 

communicate  and  request 
services  from  other  objects. 
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Definitions  (cont.) 


METHOD  An  object  class's  service  or 

behavior  in  response  to  a 
message. 


INHERITANCE  The  state  and  services  of  a 

superclass  are  available  to  a 
subclass. 


AGGREGATE  An  object  made  up  of  several 

components. 

CLASS  HIERARCHY 
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OBJECT-ORIENTED  DESIGN  (1) 


High  Level  Design 

Input  Requirements  Documents 

Costumer  Interviews 
Domain  Analysis 

Process  Identify  Domain  Object 

Classes 

Class  Design 
Divide  System 
Responsibilities 

Design  Interfaces 

Identify  Object  Reiationships 

Design  Validation 

Output  Preiiminary  design 

deliverables 
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OBJECT-ORIENTED  DESIGN  (2) 


Low  Level  Design 

Input  Preliminary  Design 

Deliverables 

Process  Identify  Internal  aspects  of 

Objects 

Data  Structure  Design 
Algorithms  for  Operations 

Identify  Object  Relationships 
Validation 

Output  Detailed  design  deliverables 
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Identification  of  Objects 


Potential  Objects  are: 

Devices  the  system  interacts  with 

Events 

Incidents 

Interactions 

Locations  of  things 

Organizations 

Remembered  Events 

Roles  of  People  or  Things 

Systems  outside  the  current  application 

Tangible  things 
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WhM<0  Hav*  aH  tha  Qbjacta  Gkma? 
Oi^aet  ktontHfeaUon  fachiriquaa 

First  phase: 

Name  Ot^ects 

A  noun  list  from  requirements  or  customer 
conversations. 

Data  Dictionary  entries* 

Data  Flow  Diagrams* 

Requirements  List* 

Use  cases 

Determine  Object's  Behavior 
A  verb  list  (Responsibilities) 

Assign  Methods  to  Ot^ects 
Eliminate  Irrelevant  Objects 
(*  Used  later  in  validation  of  object  identification) 
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Object  Identification  Techniquee  (cont.) 

Second  phase:  (using  remaining  ot^ects) 

Assign  attributes 

Abstract  superciass  objects  based  on  common 
behaviors  and  objects 

Distinguish  Private  methods  from  pubiic 
contracts 
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Automated  Video  Rutal  Svfm  Description 

Client  Request 

Mr.  Richard  wants  a  computerized  automated  video  cassette  rental  system  which 
will  be  housed  in  unmanned  kiosks.  These  kiosks  can  be  free  standing  in  mail 
parking  lots  or  can  be  placed  in  endosed  shopping  malls.  This  device,  KoFF  (Kiosk 
of  Famous  Flicks),  will  accept  applications  for  membership  in  Mr.  Richard's  Rapid 
Rental  club  (RRR),  display  titles  of  available  tapes,  dspense  tapes,  accept  returned 
tapes,  and  take  care  of  billings.  It  will  also  maintain  reports  of  rental  transactions. 

One  becomes  a  member  of  the  club  by  entering  membership  information  on  a 
keyboard  attached  to  the  kiosk.  This  information  will  include  a  current  charge  card 
number  and  an  approval  to  automatically  charge  that  card  for  selected  items 
including  a  membership  fee  of  $  10.00.  Customers  will  be  notified  of  membership 
in  RRR  by  mail  and  will  receive  three  RRR  movie  rental  cards  and  a  unique 
personal  identification  number.  Membership  expires  on  the  expiration  date  of  their 
charge  card. 

The  kiosk  contains  250  different  tape  titles  and  1380  individual  tapes.  A  customer 
can  see  a  list  of  the  available  tapes  by  category  by  inserting  one  of  their 
membership  cards  into  the  kiosk.  The  customer  can  select  an  available  tape  and 
rental  duration.  They  will  be  charged  for  it  and  the  tape  will  be  dispensed  from  the 
tape  out  slot.  Their  card  will  be  retained  until  the  tape  is  returned  to  that  kiosk. 
When  a  tape  is  returned  to  the  tape-in  slot,  its  bar  code  wilt  be  scanned,  the 
customer  will  automatically  be  charged  appropriate  late  fees  and  the  membership 
card  will  be  returned.  Failure  to  return  the  tape  within  five  days  of  its  due  date 
generates  a  phone  call  to  the  customer  which  plays  a  recorded  message  about  the 
overdue  tape  and  the  accruing  late  charges.  When  the  10-day  late  limit  is  reached, 
the  customer  is  charged  for  the  late  days  and  the  cost  of  the  tape.  The  customer 
is  also  charged  a  tape  restocking  fee  and  all  of  his/her  membership  cards  are 
invalidated.  The  customer  is  notified  of  these  actions. 

The  selection  of  videos  must  be  updated.  KoFF  keeps  information  to  help  in  this 
process.  Videos  which  have  not  been  rented  for  two  weeks  are  listed  for  removal 
and  videos  which  have  been  rented  several  times  in  a  week  are  listed  for  additional 
copies.  Every  two  weeks  KoFF  sends  Mr.  Richard's  computer  a  copy  of  this  report. 
He  decides  which  tapes  to  add  and  which  to  remove.  He  updates  the  list  of  titles 
and  records  the  quantities  of  those  titles  along  with  their  identifying  bar  codes.  He 
also  assigns  the  rental  price  for  that  title.  Sometimes  instead  of  replacing  a  slow 
moving  tape,  he  simply  drops  its  rental  price  or  tries  to  sell  it.  Sale  tapes  are 
indicated  on  a  special  screen.  When  a  customer  selects  a  sale  tape,  a  record  of 
the  sale  is  made  and  the  tape  is  dispensed. 

Mr.  Richard  gets  several  reports  from  KoFF,  including  lists  of  sold  tapes,  the  rental 
activity  of  RRR  members  by  tape  title  and  tape  category  -  Adventure,  Comedy, 
Children,  Restricted,  the  rental  activity  of  particular  titles  and  copies  of  that  title,  and 
detailed  and  summary  finandai  reports  of  RRR  member  accounts. 


14 


L270H7 


A  KoFF  Partial  Noun  List 


NOUNS 

Kiosk 

tapes 

titles 

billings 

rental  transactions 
member 


membership  information 
keyboard 

charge  card  number 

membership  fee 

movie  rental  cards 

personal  identification  number 

expiration  date 

list 


membership  card  (syn) 
available  tape 
rental  duration 
tape-out  slot 
tape-in  slot 
bar-code 


due-date 


phone-call 

late-fees 


overdue  tape 
etc. 
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A  KoFF  Partial  Noun  and  Verb  List 


Noun 

Categories 

Verbs 

Kiosk 

tapes 

tapes 

dispense,  accept, 
rer^rt,  list 

titles 

billings 

rental  transactions 

billings 

member 

member 

enter  info,  charge 
fee. 

membership  information 

issue  card 

membership  fees 
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KoFF  USE  CASES 


Rent  a  Tape 
Buy  a  Tape 
Return  a  Tape 
Membership  Card  Rejection 


Rent  a  tape: 

Conversation  with  customer:”How  do  you 
want  someone  to  rent  a  tape?" 

What  new  information  does  this  reveai? 
"What  are  the  desired  functions  for  tape 
rentai?" 


17 


L27OH10 


Examples  of  Rumbaugh  Object-Oriented 

Design  Notation 


AMMhliii: 


Nnf^wMn) 


OfUniIjnriwwi) 
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More  Examples  of  Rumbaugh  Object- 
Oriented 

Design  Notation 


Oricrbi; 


MNiAmMt:  BtrindClM: 


A||n|tiiM: 
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KoFF  USE  CASES 


Rent  a  Tape 
Buy  a  Tape 
Return  a  Tape 
Membership  Card  Rejection 


Rent  a  tape: 

Conversation  with  customer:"How  do  you 
want  someone  to  rent  a  tape?" 

What  new  information  does  this  reveal? 
"What  are  the  desired  functions  for  tape 
rentai?" 
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Examples  of  Rumbaugh  Object-Oriented 

Design  Notation 


|attrilite:4ala_iypc  i 
|attribitc:iati_^>  | 
iait  valic 


laparatiai 

afcratioiJaiLlirt): 

I  ntin_tjfc  I 


QiaUMAaMdaiin: 


MiMplktty  af  Amdatiaa: 


GHcraNntiai(Iihcritaicf): 


I  i 

j  dan  :  KuriijNc 


Mu]f(nn  train) 


OptinalJiintrMc) 
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Object  Model  Notation 
Based  on  Rumbaugh  et  al. 


Aggregation: 

A  special  form  of  association  between  a 
whole  and  its  parts. 


Association: 

A  relationship  among  instances  of  two  or 
more  classes. 


Association  as  a  class: 

Each  link  is  an  instance  of  a  class. 


Qualifier: 

Reduces  the  multiplicity  of  an  association 
at  the  many  end. 


Role: 

Appear  as  nouns  in  product  description 
and  uniquely  identify  one  end  of  an 
association. 
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Preliminaty  Design  Deliverables 


An  Object  Model: 

A  complete  object  diagram  using 
Rumbaugh  notation  as  presented  in  class. 

A  Class  Dictionary  entry  for  each  object. 

An  Object-Requirements  traceability 
matrix. 

Ada  Specifications  for  each  object  class. 

Descriptions  of  all  major  user  interfaces,  e.g., 
menu  formats  and  options. 
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CLASS  DICTIONARY 

OBJECT  CLASS  NAME: 

OBJECT  DESCRIPTION: 
ATTRIBUTE  DESCRIPTION: 

■ 

Method  Descriptions: 


Input  information  needed  from  other  objects: 
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Object  Traceability  Matrix 


Functional 

Requirement 

ID 


1 


Object  ^ 

Name  age 


MEMBER  MEMBERSHIP  OPS 
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Ada  packages 


INSTRUCHQNAL.QBJECTIYE(S): 

1 .  To  understand  the  use  and  usefulness  of  Ada  packages. 

2.  To  learn  the  syntax  of  Ada  packages. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

Soon  the  students  will  be  worldng  on  the  preliminary  design  of  their  second 
project  which  is  to  be  implemented  in  Ada.  The  prefiminary  design  is  also  to 
be  accomplished  using  Ada  package  specifications.  The  students  have  been 
introduced  to  Ada  packages  in  previous  classes. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

In  today's  lecture,  they  will  have  a  more  detailed  look  at  the  syntax  of  Ada 
packages  through  several  examples. 


CONTENTS: 

L280H1 

1 .  Give  a  brief  overview  of  three  program  units  in  Ada  -  procedures  and 
functions,  packages,  and  tasks.  Relate  procedure  and  functions  to  a 
language  students  are  already  familiar  with.  The  deveiopment  of 
packages  is  a  primary  goal  of  the  preliminary  design  team.  Be  sure 
to  emphasize  the  correspondence  between  packages  and  objects. 


2.  Detailed  look  at  Ada  packages  L280H2 

a.  A  package  is  a  collection  of  related  entities  available  for  use  by 
other  program  units.  A  package  can  include  constants, 
variables,  types,  procedures,  functions,  exceptions,  tasks,  and 
even  other  packages.  Packages  are  passive.  They  have  to  be 
invoked  by  operations  of  other  entities. 


b.  A  package  can  be  used  for  a  collection  of  declarations,  a  group 
of  related  program  units,  or  an  abstract  data  type. 

c.  There  are  two  parts  to  a  package.  They  are  stored  as  two 
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different  files,  each  having  the  same  name  but  a  different 
extension: 

i  The  specification  is  the  public  or  visible  part  which 
provides  the  interface  information  and  indicates  the 
entities  which  are  made  available  by  this  package.  The 
public  or  vissibie  part  is  what  you  are  going  to  provide 
to  the  system.  This  corresponds  to  OMT's  method  part 
of  an  ok^ect.  The  specification  can  be  created  in  the 
preliminary  design  phase  of  the  software  life  cycle. 

ii  The  body  is  the  hidden  part  which  contains  the 
implementation  details.  Knowledge  of  the  package 
details  of  the  package  body  is  not  needed  in  order  to 
use  the  package.  The  package  body  contains  the 
bodies  of  the  subprograms  which  are  declared  in  the 
package  specification.  If  also  contains  local 
declarations,  and  subprograms  which  are  inaccessible 
to  the  user  of  the  package.  The  package  body  is 
optional.  Sometimes  it  is  not  needed;  for  example,  a 
package  may  contain  only  declarations  such  as  shown 
in  L280H3. 

d.  Discuss/review  the  software  engineering  concepts  of 
abstraction,  encapsulation,  information  hiding,  modularity,  and 
reusability  and  how  these  are  supported  by  Ada  packages  as 
in  L280H4. 


e.  Ada  supports  various  levels  of  information  hiding  and 
encapsulation.  What  follows  is  a  series  of  refinements  of  an 
Ada  Queue  package,  each  of  which  more  effectively  hides  and 
encapsulates  information. 

i.  L280H5  Presents  a  package  in  which  all  data  and 
operations  are  publicly  accessible  and  the  body  L280H6 
has  minimal  details.  A  Procedure  X  could  use  a 
Queuejtype,  but  it  could  only  Enter  and  Remove.  (E.G. 
procedure  X  is 

trans  A 

QueueA,  QueueB:Queue_type; 

enter(T  ransA.QueueA) ; 

ii.  L280H7  Declares  the  Queue  type  as  a  private  type,  and 
hides  implementation  details  such  as  the  fact  that  it  is  a 
linked  list. 

iii.  L280H8  Here  a  greater  degree  of  encapsulation  is 
achieved  by  moving  all  implementation  details  to  the 
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package  body.  L280H9.  All  that  is  visible  is  the 
interface  transaction  type  and  the  two  procedures, Enter 
and  Remove.  Data  has  to  be  accessed  by  the  method 
specified  in  the  package  specification. 

f.  L280H1 1  -  If  in,  gut>  or  in  out,  is  omitted  from  a  procedure  or 
function  header,  the  parameter  defaults  to  an  jn  parameter.  In 
the  formal  parameter  list  for  a  procedure  or  function  each 
parameter  is  labeled  as  'in'  ( for  an  input  parameter),  'out'  (for 
an  output  parameter,  and  'in  out".  The  parameter  defaults  to 
in. 

PROCEDURE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  this  lecture. 

vocabulary  introduced: 

Ada  packages 
Ada  package  specification 
Ada  package  body 
private  data  type 
limited  private  data  type 


INSTRUCTIONAL  MATERIALS: 
overheads: 

L280H1  Ada  program  units 

L280H2  Ada  packages 

L280H3  Example  of  package  specification  •  Solar  System 

L280H4  Software  engineering  concepts  supported  by  Ada  packages 
L280H5  Example  of  package  specification  -  Queue 
L280H6  Example  of  package  body  -  Queue 

L280H7  Example  of  package  specification  with  data  declarations  in 
private  section  -  Queue 

L280H8  Example  of  package  body  to  go  with  overhead  7 
L280H9  Example  of  package  specification  with  all  data  inside  package 
body. 

L28OH10  Example  of  package  body  to  go  with  overhead  9 
L28QH1 1  Procedure  and  function  headers 


handouts: 


RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 
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Lab  023  Peer  reviews  and  preliminary  design  review  presentaiton 

READING  ASSIGNMENTS: 

Benjamin  Chapter  8  (pp.  73-78) 

Sommerville  Appendix(pp.  610-613) 

RELATED  READINGS: 

Booch  Chapter  6  (pp.  53-74) 

Booch(2)  Chapter  4  (pp.  43-65) 
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Ada  Program  Units 


Procedures  and  functions 


Packages 


Tasks 

Provides  concurrency 
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Ada  Packages 


A  program  unit  that  allows  a  collection  of 
related  entities  to  be  made  available  for  use 
by  other  program  units 


Two  parts  to  a  package: 

Specification 

The  public  or  visible  part 
Interface  information 


Body 


The  hidden  part 
Implementation  details 
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Software  Engineering  Concepts 
Supported  by  Ada  Packages 

Abstraction 

A  view  of  a  probiem  that  extracts  the 
essential  information  relevant  to  a 
particular  purpose  and  ignores  the 
remainder  of  the  information 
Encapsulation 

The  technique  of  isolating  data  and 
related  procedures/functions  within  a 
module  and  providing  a  precise 
specification  for  the  module 
Information  hiding 

The  technique  of  forbidding  the  use  of 
information  about  a  module  that  is  not  in 
the  module's  interface  specification 
Modularity 

The  purposeful  structuring  of  the  modules 
of  a  system  so  that  a  change  to  one 
component  has  minimal  impact  on  other 
components 
Reusability 

The  extent  to  which  a  module  can  be 
used  in  multiple  applications 
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Example  of  Package  Specification 


package  SOLAR_SYSTEM  is 

type  PLANET  is  (MERCURY,  VENUS,  EARTH, 
MARS,  JUPiTER,  SATURN,  URANUS, 
NEPTUNE,  PLUTO): 

subtype  TERRESTRIAL_PLANET  is  PLANET 
range  MERCURY..MARS: 

NUMBER_OF_MOONS:constant  array  (PLANET) 
of  NATURAL  ;=  (MERCURY  =>  0,  VENUS  => 
0,  EARTH  =>  1,  MARS  =>  2,  JUPITER  =>  12, 
SATURN  =>  1 0,  URANUS  =>  5,  NEPTUNE 
=>  2,  PLUTO  =>  0): 


end  SOLAR_SYSTEM: 
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Example  of  Package  Specification 

package  QUEUE  is 
type  TRANSACTION  is 
record 

ACCOUNTJD :  integer; 

NAME  :  string; 

ADDRESS  :  string; 
end  record; 

SIZE  :  constant  POSITIVE  :=  1 0; 
subtype  INDEX  is  integer  range  1  ..SIZE; 
type  SPACE  is  array  (INDEX)  of  TRANSACTION; 
type  QUEUE_TYPE  is 
record 

ITEMS  :  SPACE; 

HEAD  :  INDEX  :»1; 

TAIL  :  INDEX  :=1; 

COUNT  :  integer  range  0..SIZE  :=  0; 
end  record; 

procedure  ENTER  (T  :  in  TRANSACTION; 

Q  :  in  out  QUEUE_TYPE); 
procedure  REMOVE  (T  :  out  TRANSACTION; 

Q  :  in  out  QUEUE_TYPE); 

end  QUEUE; 
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Example  of  Package  Body 

package  body  QUEUE  is 

procedure  ENTER  (T  :  in  TRANSACTION; 

Q  :  in  out  QUEUE_TYPE): 

begin 

a  •  a 

end; 

procedure  REMOVE  (T  :  out  TRANSACTiON; 

Q  :  in  out  QUEUE_TYPE); 

begin 

a  a  a 

end; 

end  QUEUE; 
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Example  of  Package  Specification 

package  QUEUE  is 
type  TRANSACTION  is 
record 

ACCOUNTJD  :  integer; 

NAME  :  string; 

ADDRESS  :  string; 
end  record; 

type  QUEUE_TYPE  is  private; 
procedure  ENTER  (T  :  in  TRANSACTION; 

Q  :  in  out  QUEUE_TYPE); 
procedure  REMOVE  (T  :  out  TRANSACTION; 

Q  :  in  out  QUEUE_TYPE); 

private 

SIZE  ;  constant  POSITIVE  :=  1 0; 
subtype  INDEX  is  integer  range  1  ..SIZE; 

type  SPACE  is  array  (INDEX)  of 
TRANSACTION; 

type  QUEUE_TYPE  is 
record 

ITEMS  :  SPACE; 

HEAD  :  INDEX  :=1; 

TAIL  :  INDEX  :=1; 

COUNT  ;  integer  range  0..SIZE  :=  0; 
end  record; 
end  QUEUE; 
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Example  of  Package  Body 

package  body  QUEUE  is 

procedure  ENTER  (T  :  in  TRANSACTiON; 

Q  :  in  out  QUEUE_TYPE): 

begin 

•  a  ■ 

end; 

procedure  REMOVE  (T  :  out  TRANSACTION: 

Q  :  in  out  QUEUE_TYPE): 

begin 

•  a  • 

end; 

end  QUEUE; 
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Example  of  Package  Specification 


package  QUEUE  is 

type  TRANSACTION  is 
record 

ACCOUNTJD  :  integer; 

NAME  :  string; 

ADDRESS  :  string; 
end  record; 

procedure  ENTER  (T  :  in  TRANSACTION); 
procedure  REMOVE  (T  :  out  TRANSACTION); 
end  QUEUE; 
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Example  of  Package  Body 

package  body  QUEUE  is 
SIZE  :  constant  POSITIVE  :=  1 0; 
subtype  INDEX  is  integer  range  1..SIZE; 

type  SPACE  is  array  (INDEX)  of 
TRANSACTION: 
type  QUEUE_TYPE  is 
record 

ITEMS  :  SPACE; 

HEAD  :  INDEX  :=1; 

TAIL  :  INDEX  :=1; 

COUNT  :  integer  range  0..SIZE  :=  0; 
end  record; 

A_QUEUE  :  QUEUE_TYPE: 

procedure  ENTER  (T  :  in  TRANSACTION)  is 
begin 

•  a  a 

end; 

procedure  REMOVE  (T  :  out  TRANSACTION)  is 
begin 

a  a  a 

end; 

end  QUEUE; 
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Procedure  and  Function  Headers 

procedure  ENTER  (T  :  in  TRANSACTION): 

procedure  REMOVE  (T  :  out  TRANSACTION): 

procedure  MODIFY  (T  :  in  out  TRANSACTION): 

function  CUBE  (X  :  integer)  return  integer: 
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1 .  introduction  to  softwaro  quaiity  assurance  (SQA) 

2.  Reviews  •  waikthroughs  and  Inspections 

iNSTRUCTiONAL  QBJECTiVEfS^: 

1 .  Understand  the  scope  of  quaiity  assurance  and  the  reiated  activities. 

2.  Understand  the  purpose  of  technicai  reviews,  spedficaiiy  of 
waikthroughs  and  inspections. 

3.  Understand  generai  guideiines  for  technicai  reviews. 

SET  UP.  WARM:UP: 

(How  involve  learner:  recall,  review,  relate) 

The  issue  of  software  quality  has  come  up  in  a  number  of  earlier  lectures, 
both  directly  and  indirectly.  Recall,  for  example,  verification  and  validation 
(V&V)  -  see  L290H1.  V&V  £x;tivities  were  aimed  at  ensuring  two  things: 

1)  verifying  that  the  system  meets  its  specification  (Are  we  building  the 
product  right?);  and 

2)  validating  that  system  as  implemented  meets  the  clients'/users' 
expectations  (Are  we  building  the  right  product  right?). 

V&V  are  activities  undertaken  to  increase  the  chances  of  achieving  software 
quality.  Similarly,  recall  configuration  management  deals  with  controlling  and 
managing  change.  CM  activities  are  also  undertaken  in  order  to  increase  the 
chances  of  achieving  software  quality.  Both  V&V  and  CM  activities  are 
software  quality  assurance  (SQA)  activities. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we're  going  to  look  further  at  SQA. 

CQMIENTS: 

1.  L290H2 

Pressman  defines  SQA  as  an  "umbrella  activity"  which  encompasses 
V&V,  CM  and  a  number  of  other  types  of  activities.  SQA  is  concerned 
with  both  product  and  process  quality  and  it  encompasses: 

a.  Technical  methods  and  tools  •  These  are  used  throughout  the 
software  Nfo  cycle.  They  include  methods  and  tools  to  aid  in 
developing  high-qualty  specifications,  to  methods  and  tools  for 
implementation  and  testing. 
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b.  Technical  reviews  -  These  are  also  applied  at  every  stage  of 
the  software  life  cycle. 

c.  Testing  -  Testing  is  used  to  reveal  the  presence  of  problems  at 
any  stage  of  developement. 

d.  Configuration  management  -  The  control  and  management  of 
change  applied  to  all  artifacts  of  software  development. 

e.  Standards  -  Both  the  development  of  and  compliance  with 
standards. 

f.  Measurement  and  reporting  -  These  activities  involve 
measurement  to  track  quality  and  to  improve  quality  by 
modifying  the  process  in  light  of  these  measurements. 

Use  L290H3  and  L290H4  to  explain  the  importance  of  SQA  at  the 

beginning  of  the  development  process. 


L290H5  What  is  software  quality? 

Pressman  defines  software  quality  as  "conformance  to  explicitly  staled 
functional  and  performance  requirements,  expiidtiy  documented 
development  standards,  and  impficit  charactenstics  that  are  expected 
of  all  professionally  developed  software. 

Point  out  that  there  are  three  components  of  quality: 

a.  Meets  (explicit)  requirements;  (This  involves  the  software 
product). 

b.  Meets  (explicit)  standards;  (This  involves  the  software 
process.)  The  quality  of  the  process  affects  the  quality  of  the 
product. 

c.  Meets  (implicit)  requirements  -  these  are  standards  expected 
of  all  professionally  developed  software;  Note  that  software 
could  meet  all  of  its  explicitly  stated  requirements  yet  still  be  of 
questionable  quality.  These  are  some  things  that  a  customer 
should  expect  even  without  saying  so. 

Discuss  some  of  these  implicit  characteristics  that  should  be 
expected  of  all  quality  software?  (Let  short  discussion  bring  out 
such  things  as  maintainability,  reusability,  robustness, 
portability,  etc). 

L290H6  shows  how  quality  factors  are  evidenced  in  the  final 
product. 
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Software  reviews  -  Reviews  are  one  of  the  most  important  SQA 
activities. 

L290H7 

A  review  of  some  component  of  a  software  development  process 
serves  to  uncover  defects  so  that  they  can  be  corrected/removed 
before  going  on.  There  are  many  types  of  reviews,  both  formal  and 
informal. 

a.  The  most  common  types  of  reviews  are  called  structured 
walkthroughs  and  inspections.  In  both,  a  team  of  software 
professionals  careftjlly  reviews  an  item,  thereby  increasing  the 
chances  of  defects  being  located. 

b.  L290H8 

Technical  reviews  uncover  errors  in  the  item  under  review, 
verify  that  the  software  under  review  meets  its  requirements, 
and  ensure  conformance  to  standards.  Note  also  that  reviews 
can  serve  as  training  activities  to  new  and/or  inexperienced 
personnel. 

c.  Reviews  occur  at  meetings.  Guidelines  for  review  meetings 
typically  suggest  participation  of  3-6  appropriate  people  and 
require  advance  preparation  of  1-2  hours.  The  focus  of  the 
review  is  the  improvement  of  the  product  under  review. 

L290H9 

Roles  for  a  review  include: 

i  Review  leader  -  evaluates  review  item  for  readiness, 
distributes  review  materials  to  reviewers,  typically  a  day 
before  the  review.  The  review  leader,  like  the  other 
reviewers,  is  expected  to  spend  1  to  2  hours  reviewing 
the  material  in  preparation  for  the  review.  The  review 
leader  also  schedules  the  review  and  prepares  the 
agenda. 

ii  Recorder  -  One  of  the  reviewers  is  responsible  for 
recording  (in  writing)  all  important  issues  raised  during 
the  review. 

iii  Producer  -  The  developer  of  the  item  under  review 
"walks  through"  the  product,  explaining  the  material, 
while  reviewers  raise  issues  identified  in  their  advance 
preparation  or  during  the  review  itself. 

iv  Other  reviewers  -  Each  has  carefully  reviewed  the 
materials  and  comes  prepared  with  a  list  of  items  not 
understood  and  a  list  of  items  he/she  believes  to  be 
incorrect. 
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d.  There  are  different  methods  of  conducting  the  review.  One  is 
"participant-driven”,  in  which  each  participant  goes  through 
his/her  lists  of  unciear/incorrect  items  and  the  presenter 
responds.  Another  is  "document-driven"  in  which  the 
presenter(s)  walk  the  reviewers  through  the  item  under  review, 
and  the  reviewers  bring  up  their  concerns  as  they  are 
encountered.  The  document-driven  approach  is  more 
thorough.  In  practice,  a  majority  of  faults  in  document  driven 
walkthroughs  are  detected  by  the  presenter  during  the 
walkthrough. 

4.  L29OH10  Review  reports 

The  recorder  notes  all  issues  raised  that  need  to  be  addressed. 
These  are  summarized  at  the  end  of  the  review  and  a  "review  issues 
list"  is  produced.  A  "review  summary  report"  is  also  completed, 
containing  the  item  reviewed,  names  of  reviewers,  and  findings  and 
conclusions. 

Discuss  examples  in  in  L290H11  and  L290H12  The  review  issues 
list  identifies  problem  areas  and  serves  as  action  item  checklist  for  the 
producer  as  he/she  addresses  the  issues. 

5.  L290H13 

Discuss  the  review  guidelines,  adapted  from  Pressman. 

a.  Review  the  product,  not  the  producer. 

b.  Set  and  maintain  an  agenda. 

c.  Limit  debate  and  rebuttal. 

d.  Focus  on  identifying  problems,  not  on  attempting  to  solve  them. 

e.  Keep  a  written  record. 

f.  Limit  the  number  of  participants. 

g.  Insist  upon  advance  preparation  of  participants. 

h.  Develop  a  checklist  for  likely  review  items. 

i.  Allocate  resources  for  reviews. 

j.  Provide  appropriate  training  for  reviewers. 

k.  Establish  a  follow-up  procedure  to  assure  that  items  on  review 

issues  list  are  addressed. 
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I.  Do  not  allow  reviews  to  be  used  as  a  means  of  assessing 
participants. 

6.  Effectiveness  of  reviews  -  Evidence  has  shown  that  formal  technical 
reviews  are  extremely  effective  in  meeting  their  objectives. 

PROCEDURE: 

teaching  method  and  media: 

vocabulary  introduced: 
quality 

implicit  requirements 

explicit  requirements 

software  quality  assurance  (SQA) 

technical  reviews 

walkthrough 

inspections 


INSTRUCTIONAL  MATERIALS: 

overheads: 

L290H1 

V  &  V  activities 

L290H2 

Software  quality  assurance 

L290H3 

Source  of  errors  by  life  cycle  phase 

L290H4 

Relative  cost  of  errors  by  life  cycle  phase 

L290H5 

Software  quality 

L290H6 

McCall's  software  quality  factors 

L290H7 

Software  reviews 

L290H8 

Purpose  of  technical  reviews 

L290H9 

Review  roles 

L29OH10 

Review  reports 

L290H11 

Review  issues  list 

L290H12 

Technical  review  summary  report 

L290H13 

Review  guidelines 

RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 


Lab  024  -  User  interface  presentation/review 
Test  plan  presentation/review 

READING  ASSIGNMENTS: 

Sommerville  Chapter  31  589-598) 

Mynatt  Chapter  2  (pp.  77-79) 

RELATED  REAPINQS: 

Pressman  Chapter  17  (pp.  549-589) 

Schach  Chapter  5  (pp.  101-109) 


5 


Lecture  029 


Relationship  of  V&V  and  CM  to  SQA 

V&V  activities  aimed  at; 

Verifying  that  the  system  meets  its 
specification  (Are  we  building  the  product 
right?):  and 

Validating  that  system  as  implemented 
meets  the  clientsVusers'  expectations  (Are 
we  building  the  right  product  right?). 


CM  activities  aimed  at: 
Controlling  change  and 
Managing  change. 


V&V  and  CM  activities  are  both  undertaken  in 
order  to  increase  the  chances  of  achieving 
software  quality. 

Both  are  software  quality  assurance  (SQA) 
activities. 
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Software  Quality  Assurance  (SQA) 

SQA  is  an  "umbrella  activity"  which 
encompasses  V&V,  CM  and  a  number  of 
other  types  of  activities.  SQA  is  concerned 
with  both  product  and  process  quaiity. 

SQA  encompasses: 

Technicai  methods  and  toois 

Technical  reviews 

Testing 

Configuration  management 
Standards 

Measurement  and  reporting 

SQA  is  concerned  with  "whoie-iife  cycle" 
quality. 
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Source  of  Errors  by  Life  Cycle  Phase 

Errors  Found  Early  are  Easier 
To  Find  and  Manage 


50% 


30% 


to% 


Source  of  Errors  -  %'s 


Requirements  Software  Coding  Testing  Deployment 

Definition  Design 
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Relative  Cost  of  Errors  by  Life  Cycle  Phase 


Requirements  Software  Coding  Testing  Deployment 

Definition  Design 
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Software  Quality 

"conformance  to  explicitly  stated  functional 
and  performance  requirements,  explicitly 
documented  development  standards,  and 
implicit  characteristics  that  are  expected  of  all 
professionally  developed  software". 

source:  Pressman 


Three  components  of  software  quality 
Meets  (explicit)  requirements 
Meets  (explicit)  standards 
Meets  (implicit)  requirements 
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McCall's  Software  Quality  Factors 


MAmj  (hailiiilictintdjiBirilttiii?) 
IfficMcj  (WiilniMijhariwireai  wdiiiKtu?) 
UnUtty  (CMlruk?) 


11 


L290H6 


Software  Reviews 

One  of  the  most  important  SQA  activities. 

A  review  is  intended  to  uncover  defects  so 
that  they  can  be  corrected/removed  before 
going  on. 

Two  common  types  of  reviews: 

Waikthroughs 

inspections 


Both  invoive  a  group  of  software  professionais 
carefuliy  reviewing  an  item,  thereby  increasing 
the  chances  of  defects  being  iocated. 
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Purpose  of  Technical  Reviews 

To  uncover  errors  in  the  item  under  review. 

To  verify  that  the  software  under  review  meets 
its  requirements. 

To  ensure  conformance  to  standards. 


Reviews  can  aiso  serve  as  training  activities 
to  new  and/or  inexperienced  personnei. 
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Review  Roles 


Review  leader 

Evaluates  item  for  readiness 

Distributes  review  materials  in  advance 

Reviews  the  material  prior  to  meeting 

Schedules  review  and  prepares  agenda 

Recorder 

Records  all  important  issues  raised  during 
review 

Producer 

"Walks  through”  the  product,  explaining 
the  material,  while  reviewers  raise  issues 
based  on  their  advance  preparation 

Other  reviewers 

Review  materials  in  advance  and  come 
prepared  with  a  list  of  items  not 
understood  and  a  list  of  items  he/she 
believes  to  be  incorrect 
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Reports 


Review  issues  list 

Identifies  problem  areas  raised  during 
review  that  need  to  be  addressed 

Serves  as  action  item  checklist  for  the 
producer  as  he/she  addresses  the  issues 

Review  summary  report 
Item  reviewed; 

Reviewers; 

Findings  and  conclusions. 
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Review  Issues  List 


Review  Number :  D-004 

Date  of  Review:  07-1 1  >86 

Review  Leader :  R.S.  Pressman 

Recorder  :  A.D.  Dickerson 

Issues  U&t 

1.  Proioques  for  moduie  YMQTiON.  ZMOTIQN  are  not  consistent 
with  design  standards.  Purpose  of  the  moduie  shouid  be  expiidtiy 
stated  (reference  is  not  acceptabie)  and  data  item  dedaration 
must  be  specified. 

2.  Loop  counter  for  Interpoiation  in  X.  Y.  Z  axes  increments  one  time 
too  many  for  step  motor  control.  Review  team  recommends  a 
recheck  of  stepping  motor  specifications  and  correction  (as 
required)  of  the  loop  counter  STEP.MOTOR.CTR. 

3.  Typo  in  reference  to  current  X  position.  XPQSITiON  in  modules 
XMQTIQN  and  ZMOTIQN.  See  marked  PDL  for  specifics. 

4.  PDL  psuedo-code  statement  must  be  expanded.  The  psuedo- 
code  statement:  "Converge  on  proper  control  position  as  in 
XMOTION"  contained  in  modules  YMOTION  and  ZMOTiON 
should  be  expanded  to  specifics  for  Y  and  Z  motion  control. 

5.  Review  team  recommends  a  modification  to  the  "position 
comparator"  algorithm  to  improve  run  time  performance. 
Necessary  modifications  are  noted  in  annotated  PDL.  Designer 
has  reservations  about  the  modification  and  will  analyze  potential 
impact  before  implementing  change. 

Figure  17.6b  -  Pressman 


16 


L29CMH11 


Technical  Review  Summary  Report 


Time: 

\ 

Material  Reviewed: 

Producer:  i 

Brief  Description:  / 

Material  Reviewed:  (note  each  Item  separately) 


Review  identification: 

Project:  Review  Number: 

Date:  Location: 

Product  ldentlficall.Qni 


Review  Team:  (indicate  leader  and  controller) 
Name  Signature 


1. _ 

2. _ 

3.  _ 

4.  _ 

Product  Appraisal: 

Accepted:  as  is  ( )  with  minor  modification  ( ) 

Not  Accepted:  major  revision  ( )  minor  revision  ( ) 
Review  Not  Completed:  (explanation  follows) 

Supplementary  Material  Attached: 

issues  List  ( )  Annotated  Produce  Materials  ( ) 
Other  (describe) 


Figure  17.6b  -  Pressman 
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Review  guidelinee 

Review  the  product,  not  the  producer 

Set  and  maintain  an  agenda 

Limit  debate  and  rebuttai 

Focus  on  identifying  probiems,  not  on 
attempting  to  soive  them 

Keep  a  written  record. 

Limit  the  number  of  participants. 

Insist  upon  advance  preparation  of 
participants 

Develop  a  checklist  for  likely  review  items. 

Allocate  resources  for  reviews. 

Provide  appropriate  training  for  reviewers. 

Estabiish  a  foiiow-up  procedure  to  assure  that 
items  on  review  issues  iist  are  addressed. 

Do  not  ailow  reviews  to  be  used  as  a  means 
of  assessing  participants. 
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LECTURE  NUMBER:  030 


TOPICfS)  FOR  LECTURE: 

Review  standards  and  checklists 

ir!iSTRU£IIQNALflBJECTiyE(S): 

1 .  Understand  that  review  standards  exist  for  various  software  life  cycle 
stages  and  products. 

2.  Become  familiar  with  some  review  standards. 

3.  Become  familiar  with  the  concept  of  review  checklists,  particularly  for 
preliminary  design  reviews  and  detailed  design  reviews. 

SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

We  recently  talked  atx>ut  technical  reviews  (walkthroughs  and  inspections) 
as  a  primary  SQA  activity. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  want  to  introduce  you  to  some  accepted  standards  for  reviews. 

CONTENTS: 

1.  L30H1 

Many  professional  and  governmental  organizations  have  developed 
standards  for  SQA.  For  example,  the  DOD  has  an  SQA  standard 
which  we  have  discussed  earlier  (DQD'STD-2167A)  and  which  covers 
the  entire  software  development  life  cycle.  Other  government 
agencies  with  unique  requirements,  such  as  the  Federal  Aviation 
Administration  (FAA),  have  their  own  standards. 

L30OH2 

The  IEEE  has  a  standards  development  organization  which  builds 
quality  standards  for  many  of  the  phases  of  software  development. 
They  have,  in  feet,  developed  a  general  SQA  plan.  Discuss  aspects 
of  the  IEEE  SQA  Plan. 


2.  L30OH3 

In  order  to  achieve  SQA,  reviews  must  be  conducted  at  critical  points 
in  the  software  development  process.  Discuss  the  critical  review 
points  shown. 


3.  Checklists  have  been  developed  for  each  of  the  critical  reviews.  Such 
checklists  help  to  structure  the  reviews  and  assure  that  important 
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points  are  not  overlooked.  Discuss  examples  of  these  checklists. 

L30OH4a  -  Checklist  for  preliminary  design  review 
L30OH4a  •  Checklist  for  detailed  design  walkthrough 
L30OH5a  -  Checklist  for  code  review  -  Myers 
L30OH5b  -  continuation  of  code  review  checklist  -  Myers 
L30OH6  ‘  Preliminary  design  review  form 
L30OH7a  -  Detailed  design  review  form 
L30OH7b  -  continuation  of  detailed  design  review  form 


RRQCEPURE: 

teaching  method  and  media: 


vocabulary  introduced: 
review  standards 
review  check  lists 
critical  design  review 
system  test  review 


INSTRUCTIONAL  MATERIALS: 
overheads: 


L30OH1  IEEE  SQA  plan  -  Pressman,  p  588 

L30OH2  SQA  standards  -  Pressman,  p  589 

L30OH3  Some  important  review  points 

L30OH4  Design  review  checklist  -  Pressman 

L30OH5  Code  review  checklist 

L30OH6  Preliminary  design  review  checklist 

L30OH7  Detailed  design  review  checklist 


handouts: 


RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 


RELATED  READINGS: 

Pressman  Chapter  17  (pp.  586-590) 
Meyers  (The  Art  of  Software  Testing) 
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SQA  Standards 


DOD-STD-2167A 

DOD-STD-2168 

FAA-STD-018 

IEEE  Std.  730-1984 
IEEE  Std.  983-1986 

IEEE  Std.  1028-1988 

IEEE  Std.  1012-1986 


Software  engineering 

Software  quality 
evaluation  standard 

SQA  standard  for  the 
FAA 

SQA  plans 

Software  quality 
assurance  planning 

Software  reviews  and 
audits 

Software  verification  and 
validation  plans 
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ANSI/IEEE  Standards  730*1984  and  963*1966 
Software  QuaHty  Asaurwice  Plan 

I.  Purpose  Of  the  plan 

II.  References 

III.  Management 

A.  Organization 

B.  Tasks 

C.  Responsibilities 

IV.  Documentation 

A.  Purpose 

B.  Required  software  engineering  documents 

C.  Other  documents 

V.  Standards,  practices,  and  conventions 

A.  Purpose 

B.  Conventions 

Vi.  Reviews  and  audits 

A.  Purpose 

B.  Review  requirements 

1 .  Software  requirements  review 

2.  Design  reviews 

3.  Software  verification  and  validation  reviews 

4.  Functional  audit 

5.  Physical  audit 

6.  In-process  audits 

7.  Management  re\4ews 

VII.  Software  configuration  management 

VIII.  Problem  reporting  and  corrective  action 

iX.  Tools,  techniques,  and  methodologies 

X.  Code  control 

XI.  Media  control 

XII.  Supolier  control 

XIII.  Peo  cs  collection,  maintenance,  and  retention 


L30OH2 


Some  Important  Review  Points 


Purpose 


Systems  requirements 
review 

Understand  system  and  interface 
specifications.  Establish  major 
functional  baseline. 

Software  requirements 
review 

Assess  the  functional 
requirements  and  initiate 
preliminary  design. 

Master  test  plan 
review 

Assess  initial  master  test  plan, 
particularly  the  overall  test 
strategy. 

Preliminary  design 
review 

Assess  the  architectural  design. 
Assess  the  acceptance  and 
system  test  specs.  Establish 
preliminary  design  baseline. 

Critical  design  review 

Assess  detailed  design  including 
data  base  design.  Assess  final 
master  test  plan,  integration  and 
unit  test  specs,  and  acceptance 
test  procedures.  Authorize  start 
of  coding. 

Code  reviews 

Assess  units  of  code.  Establish 
test  baseline. 

System  test  review 

Assess  systems  test  results. 
Determine  readiness  for 
acceptance  testing. 

Acceptance  test 
review 

Assess  acceptance  test  results. 
Accept  software  package.  Create 
product  baseline  and  approve 
operational  implementation. 

esign  Review  Checklists  -  Pressman 
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1 .  Are  software  requirements  reflected  in  the 
software  architecture? 

2.  Is  effective  modularity  achieved?  Are 
modules  functionally  independent? 

3.  Is  the  program  architecture  factored? 

4.  Are  interfaces  defined  for  modules  and 
external  system  elements? 

5.  Is  the  data  structure  consistent  with  the 
information  domain? 

6.  Is  the  data  structure  consistent  with 
software  requirements? 

7.  Has  maintainability  been  considered? 

8.  Have  quality  factors  been  explicitly 
assessed. 
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Design  Review  ChecMists  -  Presentan 


Detailed  Design  walkthrough 

1 .  Does  the  algorithm  accomplish  the 
desired  function? 

2.  Is  the  algorithm  logically  correct? 

3.  Is  the  interface  consistent  with 

architectural  design? 

4.  Is  the  logical  complexity  reasonable? 

5.  Have  local  error  handling  and 

"antibugging"  been  specified? 

6.  Are  local  data  structures  properly  defined? 
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Code  Review  Checldists  (Glenfoixl  Meyere) 


Data  reference 

1 .  Unset  variables  used? 

2.  Subscripts  within  bounds? 

3.  Non-integer  subscripts? 

4.  Dangling  references? 

5.  Correct  attributes  when  aliasing? 

6.  Record  and  structure  attributes  match? 

7.  Computing  addresses  of  bit-strings? 

8.  Passing  bit-string  arguments? 

9.  Based  storage  attributes  correct? 

10.  Structure  definitions  match  across 
procedures? 

1 1 .  String  limits  exceeded? 

12.  Off-by-one  errors  in  indexing  or 
subscripting  operations? 


1 .  All  variables  declared? 

2.  Default  attributes  understood? 

3.  Arrays  and  strings  initialized  properly? 

4.  Correct  lengths,  types,  and  storage 
classes  assigned? 

5.  Initialization  consistent  with  storage  class? 

6.  Any  variables  with  similar  names? 
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Code  Review  Checkliets 


I 

i 

I 

Computation 

1.  Computations  on  non-arithmetic 
variabies? 

2.  Mixed-mode  computations? 

3.  Computations  on  variabies  of  different 
iengths? 

4.  Target  size  iess  than  size  of  assigned 
value? 

5.  Intermediate  result  overflow? 

6.  Division  by  zero? 

7.  Base-2  inaccuracies? 

8.  Variable's  value  outside  of  meaningful 
range? 

9.  Operator  precedence  understood? 

1 0.  Integer  divisions  correct? 

Comparison 

1.  Comparisons  between  inconsistent 
variables? 

2.  Mixed-mode  comparisons? 

3.  Comparison  relationships  correct? 

4.  Boolean  expressions  correct? 

5.  Comparison  and  boolean  expressions 
mixed? 

6.  Comparisons  of  base-2  fractional  values? 

7.  Operator  precedence  understood? 

8.  Compiler  evaluation  of  boolean 
expressions  understood. 
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Preliininary  Design  Review  Form 


Project  Name _ 

Reviewer  Name _ 

I.  High  Level  Issues 

A.  Requirements:  any  requirements  missed, 
requirements  over-worked? 


B.  Design  :  suggestions  for  improvement  of 
architecture  or  procedures;  other 
strategies 


II.  Design  Deliverable  Details 

A.  Test  Plan:  items  over-tested  or  under¬ 
tested,  suggested  tests 


B.  DFD:  good  use  of  notation,  clear  model, 
suggested  improvements 


C.  Comments  on  other  deliverables 
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Detailed  Design  Review  Form 

Project  Name  _ 

Reviewer  Name  : _ 

I.  High  Levei  issues 

A:  Requirements:  any  requirements  missed, 
requirements  over-worked? 

B:  Design  :  suggestions  for  improvement  of 
architecture  or  procedures;  other 
strategies 

C:  The  Design  fits  the  whole  specification 
including  quality  standards  such  as 
flexibility,  friendliness,  efficiency,  and  cost 
effective. 

II  Design  Deliverable  Details 

A:  Revised  Test  Plan;  items  over  tested  or 
under-tested,  suggested  tests 


B:  Design  Model:  good  use  of  notation,  clear 
model,  suggested  improvements 
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Ill  Detailed  Design 


A:  Can  design  be  implemented  easily: 
availability  of  adequate  programming  and 
testing  manpower.  Adequate  hardware 
facilities-computer,  data  storage... 


B:  Is  the  design  programmable-  does  not 
require  exotic  functions 

C:  Is  there  a  suggested  or  obvious  order  of 
implementation  or  approximate  times  for 
the  development  of  and  description  of  the 
production  relations  between  the  modules. 

What  is  the  order  of  need  for  equipment 
required  to  implement  the  design. 

D:  Comments  on  other  deliverables 
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LECTURE  NUMBER:  031 

TOPIC(S)  PQR  LECIUBE: 

The  relation  between  detailed  and  high  level  design. 

Detailed  design  procedures. 

Detailed  design  deliverables. 

INSTRUCTIONAL  OBJECTIVEfS): 

1 .  Develop  a  detailed  design. 

2.  Understand  diftorent  products  of  detailed  design 

SET  UP.  WARIVmP.: 

(How  involve  learner:  recall,  review,  relate) 

Last  time,  when  we  spoke  of  design,  we  looked  at  the  general  elements  of 
object-oriented  design  and  paid  particular  attention  to  the  elements  of 
preliminary  design.  One  of  the  questions  we  addressed  in  structured  design 
was  "How  does  one  develop  a  design  from  the  analysis  documents.”  Today 
we  will  look  at  a  similar  question  for  object-oriented  development. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

How  does  one  move  from  preliminary  object-oriented  design  to  detailed 
object-oriented  design  and  what  are  the  products  of  detailed  object-oriented 
design? 

Ci3NTEbLTS: 

1.  Design  consists  of  several  steps  L310H1 


L310H2 

2.  Briefly  remind  them  of  the  elements  that  make  up  objects.  Show  them 
a  sample  notation  from  the  KoFF  System  on  the  board  using 
Rumbaugh  notation.  For  example  the  subclasses  of  tapesJor_sale 
and  tapes Jo_rent  inherit  all  class  attributes  from  the  superclass 
TAPE.  L310H3  show  the  notation  for  inheritance  and  an  association 
between  the  Member  object  class  and  the  Tape  object  class. 


3.  Revisit  the  stages  of  preliminary  design  and  discuss  some  sample 
products  of  preliminary  design.  L31 OH4 

a.  Talk  about  the  Ot^ect  Traceability  Matrix  and  how  it  functions 
to  validate  the  design.  It  also  helps  to  show  the  completeness 
of  the  design.  L310H5 

Verification  matrices  tie  Ada  software  components  to  the 
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deliverables  of  the  previous  development  phases  (i.e., 
preliminary  and  det£uled  design).  These  verification  matrices 
provide  a  means  of  tracing  the  transitions  between  all  pheises 
of  the  life  cycle.  For  example,  by  means  of  a  verification  matrix 
for  preliminary  design,  every  Ada  package  specification  can  be 
traced  back  to  an  object  in  the  object  model,  and  that  object, 
in  turn,  can  be  traced  back  to  the  requirement(s)  which  it 
satisfies.  In  this  way,  verification  matrices  make  visible  the 
relationship  of  Ada  to  software  analysis  and  design. 

b.  When  the  preliminary  design  is  complete  it  should  be  compared 
to  the  functional  requirements  list  for  consistency  and 
completeness.  Each  requirement  must  be  satisfied  in  the 
design  and  each  design  element  must  be  tied  to  a  requirement. 


L310H6 

c.  Discuss  the  contents  and  function  of  the  Class  Dictionary  and 
how  it  provides  traceability  to  the  Ada  specification  for  each 
object.  It  is  through  the  dictionary  that  an  Ada  specification  is 
tied  to  an  object  and  the  object  is  tied  to  a  requirement  through 
the  traceability  matrix. 

d.  Point  out  that  reusability  is  actually  improved  because  the 
Class  Dictionary  does  not  include: 

i  implementation  decisions 

ii  data  type  specifications 

iii  how  operations  accomplish  their  tasks 

iv  where  an  object's  methods  are  called  from 

e.  Similarly  Ada  specifications  provide  interface  information  but 
they  shouid  not  provide  any  of  the  items  in  d.  above.  This 
information  should  be  put  in  the  body  of  the  package. 


Detailed  design  is  the  selection,  specification,  design  and 
representation  of  the  internal  aspects  of  objects.  Show  the  detailed 
design  overhead  L31OH10.  Make  clear  that  detailed  design  is  not 
intended  to  change  any  object  interface  and  therefore  should  not  alter 
the  preliminary  design.  Since  implementation  details  were  not  shown 
in  preliminary  design's  Ada  specifications  or  object  modei,  detailed 
design  should  not  impact  preliminary  design.  L310H7  Visible  data 
structures  are  declared  in  the  package  specification  and  hidden  data 
structures  are  declared  in  the  body.  Visible  data  structures 
characterize  the  data  to  be  passed  to  other  independent  packages 
while  the  hidden  data  structures  characterize  variables  used  in  the 
formulation  of  internal  operations.  This  may  inciude  defining  internal 
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values  of  variables.  This  is  a  good  example  of  modularization 
process. 


5.  The  design  of  the  data  structures  at  this  stage  is  significant  for  later 
ease  and  quality  of  the  implementation.  Discuss  some  standards  of 
data  structure  design.  When  discussing  coupling  and  cohesion  as  a 
standard,  be  sure  to  point  out  that  there  is  coupling  and  cohesion 
within  an  object  and  between  objects. 

6.  The  data  structure  design  is  documented  in  the  data  dictionary.  Show 
the  Data  Structure  Dictionary  and  discuss  how  to  fill  it  out.  L310H8 
The  algorithms  for  each  method  will  also  be  specified  in  some  pseudo¬ 
code,  such  as  Nassi  Shneiderman  models. 


7.  Show  the  Detailed  Design  Traceability  Matrix  and  discuss  how  to  fill 
it  out.  L310H9 

To  establish  traceability  between  software  development  phases,  we 
have  also  designed  an  object  traceability  matrix  (Figure  4).  This 
matrix  provides  a  backward  trace  from  each  design  object  to  a  specific 
requirement  (preliminary  design  traced  to  requirements)  and  a  forward 
trace  from  each  design  object  to  a  specific  Ada  specification 
(preliminary  design  traced  to  detailed  design).  The  introduction  of  this 
form  allows  us  to  revisit  the  concept  of  traceability  in  the  software  life 
cycle. 


Traceability  is  extended  into  detailed  design  by  means  of  a  detailed 
design  traceability  matrix.  We  created  this  matrix  to  provide 
traceability  between  preliminary  design,  detailed  design  and 
implementation.  The  detailed  design  matrix  first  provides  traceability 
between  an  object's  attributes  and  its  data  structures  and  between 
those  data  structures  and  their  Ada  package  representation.  The 
matrix  also  provides  traceability  between  the  object's  operations,  the 
detailed  design  model  of  those  operations  and  the  Ada  package 
embodying  those  operations. 


8.  Detailed  design  should  also  expand  upon  the  user  interface  developed 
in  preliminary  design.  Suppose  for  example  the  preliminary  design 
team  specified  the  format  for  the  screen  used  to  call  help.  The  type 
of  content  needed  by  each  help  screen  should  be  determined  in 
detailed  design,  e.g.,  will  help  screens  have  an  option  to  do  a  core 
dump  or  merely  an  option  to  abort  or  continue  processing. 
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L31OH10,L31OH11 

9.  These  are  the  deliverables  of  preliminary  and  detailed  design.  There 
may  be  some  continuing  problems  which  need  to  be  addressed. 
There  is  a  possibility  that  this  low  level  design  wiii  reveal  problems 
with  the  earlier  stages  of  the  software  development.  Problems  could 
include  missing,  contradictory  or  non*feasible  requirements.  They 
could  also  include  requirements  which  were  not  satisfied  by  the 
preliminary  design.  Before  any  changes  can  be  made,  configuration 
management  is  alerted.  The  traceability  matrixes  enables 
configuration  management  to  determine  the  relationship  between  any 
element  in  design  and  the  requirements. 


10.  The  next  lecture  will  present  a  method  for  annotating  the  algorithm  of 
an  objects  methods  or  operations. 


PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 

object  traceability  matrix 

class  dictionary 

Nassi  Shneiderman  model 

Data  Structure  Design  Trace  Mathx 


INSTRUCTIONAL 

fi.veriiead?' 

L310H1 

L310H2 

L310H3 

L310H4 

L310H5 

L310H6 

L310H7 

L310H8 

L310H9 

L31OH10 

L310H11 


MATERIALS: 

Outline 

Definitions 

Rumbaugh  Model 

Object  oriented  preliminary  design 

Object  Traceability  Matrix 

Class  Dictionary 

Object  oriented  detailed  design 

Data  structure  dictionary 

Detailed  design  traceability  matrix 

Detailed  design  deliverables 

Preliminary  design  deliverables 
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(labs  and  exercises) 

Lab  025  -  Resolution  of  outstanding  issues  from  last  semester 


Mynatt  Chapter  1  (pp.  31-42) 
Mynatt  Chapter  3  (pp.  94-138) 
Mynatt  Chapter  4  (pp.  169-183) 


Schach  Chapter  10  (pp.  321-324) 
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OUTLINE 


Design 

High  Level  Design  (Preliminary 
Design) 

Low  Level  Design  (Detailed  Design) 

Steps  in  Low  Levei  Design 

Notation  to  Express  the  Low  Level 
Design  Model 

Detailed  Design  Deliverables 


6 


L310H1 


Definitions 


OBJECT  CLASS  Models  "things"  in  the  world; 

the  model  has  attributes, 
operations,  and  a  precise 
interface  that  receive 
messages.  ( a  factory 
waiting  to  create  instances) 

INSTANCE  An  actual  object  waiting  to 

perform  services  and  having 
state,  (the  object) 

ENCAPSULATION  An  object's  state  data 

cannot  be  directly  accessed, 
it  can  only  be  asked  for  a 
service. 

MESSAGE  The  only  way  objects 

communicate  and  request 
services  from  other  objects. 

METHOD  An  object  class's  service  or 

behavior  in  response  to  a 
message. 
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r^etclirtel 

citelbtetipcf 


OBJECT-ORIENTED  PRELIMINARY  DESIGN 


High  Level  Design 

Input  Requirements  Documents 

Costumer  interviews 
Domain  Anaiysis 

Process  identify  Domain  Object 

Classes 

Class  Design 
Divide  System 
Responsibiiities 

Design  Interfaces 

Identify  Object  Reiationships 

Design  Vaiidation 

Output  Preiiminary  design 

deliverabies 
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Object  Traceability  Matrix 

FunctionEd  Object  Name  Ada  Package 

Requirement  id. _ _ _ 

1  MEMBER  MEMBERSHIP 

OPS 
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CLASS  DICTIONARY 

OBJECT  CLASS  NAME: 

OBJECT  DESCRIPTION: 
ATTRIBUTE  DESCRIPTION: 

■ 

Method  Descriptions: 


input  information  needed  from  other  objects: 


11 


L310H6 


OBJECT-ORIENTED  DETAILED  DESIGN 

Low  Level  Design 


Input 


Process 


Output 


Preliminary  Design 
Deliverables 


Identify  Internal  aspects  of 
Objects 

Data  Structure  Design 
Data  Structure 
Dictionary 

Algorithms  for 
Operations 

Nassi-Shneiderman 

Models 


Identify  Object  Relationships 
((Update  the  Object 
Model  with  permission 
from  CM)) 


Detailed  design  deliverables 
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Data  Structure  Dictionary 


OBJECT  CLASS  NAME: 

Ada  PACKAGE  NAME: 

DATA  STRUCTURE  NAME: 

ATTRIBUTE(S)  COVERED: 

DESCRIPTION: 

use  data  dictionary  notation 
suggest  a  data  type 
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Detailed  Design  Traceability  Matrix 


Data  Structure 

Objects  and 

Ada 

Name 

Attributes 

Package 

Member__Record 

MEMBER  NAME 

MEMBERSHIP 

• 

MEMBER_FEE 

_OPS 

• 

OPERATIONS 

Nassi-Shneiderman 

Ob]ect_ 

Ada 

Model  Name 

Operations 

Package 

ENROLL  MEMBER  ENROLL  MEMBERSHIP  OPS 
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DETAILED  DESIGN  DEUVERABLES 


Data  Structure  Design 

Data  Structure  Dictionary 
object  entries 
attribute  entries 

Algorithm  Design 

Nassi-Shneiderman  (NS)  models  for 
each  operation 

Traceability  Matrix 

Data  structures  are  related  to 
Object_Attribute 

NS  models  are  related  to 
Object_Operations 

Detailed  user  interfaces 

Report  Formats 

Low  level  menu  content,  e.g., 
categories  of  menu  information 
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Preliminary  Design  Deliverables 


An  Object  Model: 

An  complete  object  diagram  using 
Rumbaugh  notation  as  presented  in  class. 

A  Class  Dictionary  entry  for  each  object. 

An  Object-Requirements  traceabiiity  matrix. 

Descriptions  of  aii  major  user  interfaces, 
e.g.,  menu  formats  and  responses 

Ada  Specifications  for  each  object  class. 


16 


L310H11 


LECTURE  NUMBER:  032 


TQPIC(S)  FOR  LECTURE: 

Reuse 


INSTRUCTIONAL  OBJECTIVES): 

1 .  To  understand  the  role  of  reuse  in  the  development  of  software. 

2.  To  learn  the  language  features  of  Ada  which  support  reuse. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

One  of  the  primary  considerations  in  design  is  reuse.  This  can  be  achieved 
by  the  design  and  development  of  reusable  modular  components.  Reuse 
supports  maintainability,  testability,  and  consequently  reduces  the  amount  of 
effort  needed  to  develop  quality  systems. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

In  today's  lecture  we  will  examine  the  issue  of  reuse. 


CONTENTS: 

1.  Introduction  to  the  concept  of  reuse  L320H1 

a.  Reuse,  according  to  the  IEEE  definition,  is  the  extent  to  which 
a  module  can  be  used  in  multiple  applications.  Usually,  we  are 
talking  about  the  reuse  of  code,  but  reuse  throughout  the  life 
cycle  would  also  increase  productivity.  Reuse  of  design,  part 
of  a  manual,  or  set  of  test  data  are  examples  of  other  types  of 
reuse  which  may  become  more  common  in  the  future,  in 
relation  to  code,  reuse  is  the  use  of  components  of  one  product 
in  order  to  facilitate  the  devebpment  of  a  different  product  with 
different  or  similar  functionality. 

b.  As  will  be  seen  later  in  the  Ada  examples,  components  must  be 
generalized  in  order  to  provide  for  reuse.  Components  must 
also  be  written  so  that  they  are  understandable,  documented 
according  to  a  set  of  organizational  standards,  and  portable. 
L320H2 

These  attributes  are  needed  if  the  components  are  to  be 
understood  and  adaptable.  Designing  for  reuse  is  more  time- 
consuming  than  designing  for  a  particular  functionality; 
therefore,  there  needs  to  be  an  organizational  policy  decision 
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for  reuse  to  be  successful.  Project  managers  must  be  willing 
to  invest  extra  effort  for  long-term  benefits  instead  of  working 
only  towards  immediate  results. 

c.  Increased  productivity  is  a  primary  benefit  of  reuse.  Increased 
productivity  which  equates  to  savings  in  time,  effort,  and  cost 
during  development  is  a  result  of  having  fewer  components  to 
design,  implement,  and  validate.  Other  benefits  are  shown  on 
overhead. 

L320H3 

d.  However,  there  are  several  problems  hindering  widespread 
reuse  in  industry  in  the  United  States  (reuse  is  more  common 
in  Japan  and  Europe).  These  problems  are  shown  on 
overhead  L320H4. 

e.  Four  main  types  of  reuse  of  code  are  application  systems, 
subsystems,  modules  or  objects,  and  functions.  L320H5 
Reuse  of  application  systems  is  the  portability  of  application 
systems  over  a  range  of  machines.  This  type  of  reuse  is 
commonly  dene  already.  Reuse  of  functions  is  also  already 
commonly  accomplished;  for  example,  a  library  of  mathematical 
functions  is  a  common  feature  for  programming  environments. 


Ada  supports  reuse  in  these  ways:  generics,  passing  subprograms, 
and  unconstrained  arrays  L320H6. 

a.  A  generic  unit,  which  is  a  parameterized  template,  provides  for 
reuse.  The  instantiation  of  a  generic  tailors  that  generic  to  a 
specific  function.  Ada’s  support  generics  for  procedures, 
functions,  and  packages.  There  are  three  aspects  to  defining 
and  using  generics:  generic  unit  declaration,  generic 
subprogram  or  package  body,  and  instantiation  of  an  instance 
of  the  generic  unit.  L320H7,  L320H8,  L320H9, 

L32OH10 


L320H7  is  an  example  of  a  generic  procedure  to  interchange 
two  items.  L32OH6-L32OH10  is  an  example  of  a  generic  stack 
package. 

b.  Compilation  units  can  be  reused  in  different  contexts  based  on 
the  passing  of  types  and  subprograms  as  parameters. 
L320H11,  L320H12,  L320H13  is  an  insertion  sort  which 
demonstrates  this. 
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c.  The  use  of  unconstrained  arrays  allows  arrays  to  be 
dynamically  allocated;  instead  of  having  to  specify  the 
dimensions  at  compile  time  as  in  Pascal.  L320H14 


PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 
reuse 
generic 
instantiation 
unconstrained  array 


INSTRUCTIONAL  MATERIALS: 
overheads: 

L320H1  Reuse 

L320H2  Factors  in  implementing  reuse 

L320H3  Benefits  of  reuse 

L320H4  Problems  hindering  reuse 

L320H5  Types  of  reuse 

L320H6  Ada  and  reuse 

L320H7  Example  of  generic  procedure 

L320H8  Example  of  generic  package  specification 

L320H9  Example  of  generic  package  body 

L32OH10  Example  of  generic  instantiation 

L320H11  Example  of  passing  types  and  subprograms  package 
specification 

L320H1 2  Example  of  passing  types  and  subprograms  package  body 

L320H1 3  Example  of  passing  types  and  subprograms  instantiation 

L320H14  Example  of  Pascal  array 


handouts: 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  026  -  Reorganization  of  extended  project 
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READING  ASSIGNMENTS: 

Sommerville  Chapter  16  (pp.  309-328) 

Benjamin  Chapter  9  and  12  (pp.  79-85  and  111-117) 


RELATED  READINGS: 

Berzins  Chapter  8  (pp.  467-492) 
Booch  Chapter  14  (pp.  253-1^) 
Booch(2)  Chapter  12  (pp.  252-255) 
Ghezzi  Chapter  2  (pp.  28-29) 
Pressman  Chapter  1  (pp.  13-15) 
Schach  Chapter  15  (pp.  483-484) 
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Reuse 


The  extent  to  which  a  module  can  be  used  in 
multiple  applications  [IEEE] 


Practice  of  taking  portions  of  previously 
developed  software  and  using  them  in  new 
software,  perhaps  with  some  minor  alterations 


Accomplished  in  design  -  design  for  reuse 


s 


L320H1 


Factors  in  Implementing  Reuse 


Components  must  be  generalized  to  satisfy  a 
wider  range  of  requirements 


Requires  an  organizational  policy  decision  to 
increase  short-term  costs  for  long-term  gain 


Components  should  be  understandable, 
documented  according  to  a  set  of 
organizational  standards,  and  portable 
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Benefits  of  Reuse 


Considerable  savings  in  time,  effort,  and  cost 
during  development 


Increase  in  system  reliability 


Reduction  in  overall  risk 


Effective  use  of  specialists 


Embodiment  of  organizational  standards  in 
reusable  components 
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Problems  Hindering  Reuse 


Need  for  properly  catalogued  and  documented 
base  of  reusable  components 


Organizations  are  reluctant  until  the  cost- 
effectiveness  of  reuse  is  demonstrated 


CASE  tools  do  not  support  reuse 


Confidence  ievel  among  software  engineers 
for  reusable  components  is  still  low 


Legal  issues  over  ownership  of  contract 
software 
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Types  of  Reuse 


Application  systems 


Subsystems 


Modules  or  objects 


Functions 
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Ada  and  Reuse 


Generics 


Passing  of  types  and  subprograms  as 
parameters 


Unconstrained  arrays 
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Example  of  Generic  Procedure 

-header 

generic 

type  ITEM  is  private; 

procedure  INTERCHANGE  (FIRST,  SECOND  : 

in  out  ITEM); 


-body 

procedure  INTERCHANGE  (FIRST,  SECOND  : 

in  out  ITEM)  is 

TEMP  :  iTEM; 
begin 

TEMP  :=  FiRST; 

FiRST  :=  SECOND; 

SECOND  :=  TEMP; 
end; 


..jnstsncG 

procedure  iNTEGERJNTERCHANGE  is  new 
INTERCHANGE  (ITEM  »>  integer); 

-instance 

procedure  BOOLEANJNTERCHANGE  is  new 
INTERCHANGE  (ITEM  »>  boolean); 
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Example  of  Generic  Package  Specification 


generic 

SIZE  :  positive; 
type  ITEM  is  private; 
package  STACK  is 
procedure  PUSH  (X :  in  ITEM); 
procedure  POP  (X  :  out  ITEM); 

STACK_OVERFLOW, 
STACK_UNDERFLOW  :  exception; 
end  STACK; 
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Example  of  Generic  Package  Body 

package  body  STACK  is 
SPACE  :  array  (1  ..SIZE)  of  ITEM; 

INDEX  :  integer  range  0..SIZE  0; 

procedure  PUSH  (X  :  in  ITEM)  is 
begin 

if  INDEX  »  SIZE  then 
raise  STACK_OVERFLOW; 

6lS6 

INDEX  :=  INDEX  +  1 ; 

SPACE  (INDEX)  :=  X; 
end  if; 
end  PUSH; 

procedure  POP  (X  :  out  ITEM)  is 
begin 

if  INDEX  »  0  then 
raise  STACK_UNDERFLOW; 

6lS6 

X  :=  SPACE  (INDEX); 

INDEX  :=  INDEX  - 1 ; 
end  if; 
end  POP; 
end  STACK; 
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Example  of  Generic  Instantiation 


package  INTEGER_STACK  is 
new  STACK  (10,  integer); 


type  EMPLOYEE  is 
record 

NAME  ;  string  (1  ..40); 

ID  :  integer; 
end  record; 

package  EMPLOYEE_STACK  is 
new  STACK  (SIZE  =>  25, 

ITEM  =>  EMPLOYEE); 
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Example  of  Passing  Types  and  Subprograms 
Procedure  Specification 


generic 

type  ITEM  is  private; 

type  VECTOR  is  array  (integer  range  <>)  of 
ITEM; 

with  function  ">"  (A,B  :  ITEM) 
return  BOOLEAN  is  <>; 

procedure  INSERTION_SORT(A  in  out 
VECTOR); 
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Example  of  Passing  Types  and  Subprograms 

Proc^ure  Body 


procedure  INSERTION_SORT(A  in  out 
VECTOR)  is 
I,  J  ;  integer; 

T  :  iTEM; 

L  :  integer  :=  A'first; 

U  :  integer  :=  A'last; 
begin 
I  :=  L; 

while  I  /s  U  loop 
T:=A(I  +  1): 

J  :=  I  +  1 ; 

while  J  /=  L  and  then  A  (J  - 1 )  >  T  loop 
A  (J)  :=  A  {J  - 1): 

J  :=  J  - 1 ; 
end  loop; 

A  (J)  :=  T; 

I  :=  I  +  1 ; 
end  loop; 

end  INSERTION_SORT; 


16 


L320H12 


Example  of  Passing  Types  and  Subprograms 

Instantiation 


type  EMPLOYEE  is 
record 

NAME  :  string  (1..40): 

ID  :  integer; 
end  record; 

type  EMPLOYEE_ARRAY  is  array  (integer 

range  <>) 

of  EMPLOYEE; 

function  ">"  (A,B  :  EMPLOYEE)  return  boolean  is 
begin 

return  A.ID  >  B.ID; 
end; 

procedure  EMPLOYEE_SORT  is  new 
INSERTION_SORT  (ITEM  =>  EMPLOYEE, 

VECTOR  =>  EMPLOYEE_ARRAY, 

">"  =>  ">"); 


procedure  EMPLOYEE_SORT  is  new 
INSERTION_SORT  (EMPLOYEE, 

EMPLOYEE_ARRAY,  V); 
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Example  of  Pascal  Array 


const 

SIZE  =  17; 
type 

MATRIX  =  array  [1  ..SIZE,  1  ..SIZE]  of  char; 

procedure  TRANSPOSE_MATRIX 
(IN_MATRIX  :  MATRIX; 
var  OUT_MATRIX  :  MATRIX): 


Example  of  Ada  Unconstrained  Array 


type  MATRIX  is  array  (integer  range  <>, 

integer  range  <>)  of  character; 

procedure  TRANSPOSE_MATRIX 
(IN_MATRIX  :in  MATRIX; 

OUT_MATRIX  :  out  MATRIX); 


18 


L320H14 


Nassi-Shneiderman  Chart  notatior) 


INSTRUCTIONAL  OBJECTIVEfS^: 

1.  To  learn  Naesl-Shneiderman  Chart  notation  for  representing 
algorithms  used  In  detailed  design. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

We  have  begun  looking  at  deteUied  design.  The  algorithms  developed  in 
detailed  design  must  be  dearly  communicated  at  a  high  level  of  abstraction 
but  which  can  also  be  easily  implemented.  One  such  notation  is  Nassi 
Shneiderman  diagrams. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  will  look  at  a  notation  for  representing  detailed  design. 


CQNIENIS: 

1 .  There  are  a  number  of  ways  to  represent  algorithms.  Although  the 
most  commonly  used  is  pseudo-code,  we  chose  to  use  Nassi 
Shneiderman  diagrams.  We  chose  them  in  order  to  discourage 
students  from  writing  code  during  design.  Discuss  the  advantages 
and  disadvantages  of  Nassi  Shneiderman  charts  (NSC).  L330H1 

L330H2 

2.  Present  the  students  with  the  notation  and  rules  for  creating  NSC. 

3.  The  three  basic  constructs  for  representing  any  algorithm  are 
sequence,  selection,  and  iteration.  Discuss  the  Nassi-Shneiderman 
Chart  notation  for  these  are  shown  in  overhead  L330H3. 

4.  Discuss  the  more  complicated  examples  given  in  overheads  L330H4. 
L330H5.  L330H6.  L330H7. 


PROCEDURE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  this  lecture. 
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INSTRUCTIONAL 

OYgrhMds: 

L330H1 

L330H2 

L330H3 

L330H4 

L330H5 

L330H6 

L330H7 

L330H8 


MATERIALS: 

Nassi-Shneiderman  Charts 

Rules  for  drawing  and  creating  Nassi-Shneiderman  charts 

Notation  for  sequence,  selection,  and  iteration 

Example  notation  for  complex  IF  statements 

More  Complex  IF  statements 

Example  notation  for  CASE  statements 

Example  notation  for  a  procedure 

Example  notation  for  DO  WHILE  loop 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  027  -  Nassi-Shn»derman  charts 

Preparation  for  detailed  design  review 

Use  Lab  to  have  the  students  practice  NSCs. 

READJNC  ASSIGNMENTS: 

Mynatt  Chapter  5  (pp.  198-202) 


RELATED  READINGS: 

Pressman  Chapter  10  (pp.  345-350) 
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Nassi-Shneiderman  Charts 


Method  for  representing  structured  algorithms 


Advantages: 

Easy  to  learn 
Easy  to  read 

Easy  to  convert  to  source  code 

Good  at  encouraging  structured  design 
Flexible  in  the  level  of  detail  shown 

Standardized 


Disadvantages: 

Difficulty  in  drawing  and  modifying  if 
no  access  to  CASE  tool  that  provides 
this  notation 
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Rules  for  Drawing  and  Creating 
Nassi’Shnaidarman  Charts 


The  charts  are  always  rectangular. 

The  flow  of  control  In  a  Nassi-Shneiderman  chart 
always  starts  at  the  top. 

Flow  of  control  always  moves  from  top  to  bottom, 
except  when  iteration  is  invoived. 

Vertical  lines  may  never  be  crossed. 

A  rectangle  may  be  exited  in  a  downward  direction 
oniy. 

A  rectangle  may  be  empty,  representing  null  or 
empty  action. 

A  rectangle  may  represent  another  Nassi- 
Shneiderman  chart  (for  exampie,  a  call  to  another 
procedure). 


(Mynatt) 
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Nassi-Shneiderman  Notation 
For  Complex  If  Statements 


IF  ititeaeit  (miUfk  eHiMm) 


NISTID  IF  STATEMENT 

I.  LiiMruiteSIFititeBeit 
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Nassi-Shneiderman  Notation 
Another  Example  of  a  Complex  IF  Statement 


k.  Nn-HifiriciliilFililiBfit 
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Nassl-^hnelderman  Notation 
for  CASE  Statements 


Cikilitc  Siki  Cmainiii 


M  lettiLPriee,  Tninitki.CMle,  Iif.Ni 


Tnittcttoi.Ciie 


liMiiiki” 

C*Miiioi  ■ 

Ictiil  jrUe  *  MS 

CiMiuiii* 

UUl.Prkc*M7 

Iitia_PriceM.l 

CiMiniM 

icri 

Priit  Ictil.Prke,  Cmkiiii, 

Nassi-Shneiderman  Notation 
for  Case  Statements 
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Nassi-Shneiderman  Notation  for 
Nested  IF  Statements 


CoHpite.Enptoyee.Fiy 


SttAl.ntUiJiNtotni 

Scterrsr_ieMi|etiUiik 

leid  Eap.N*,  Fiy.Iite,  Hn.Wirked 

Fiy_Rite>S2S.M 

Yei  - 

No 

trnr_aeutit^ 

'  ftj  Iite  ciceedi 

'$2s.ir 

i  A  Fitldi  ViUd- 
(ibc 

yIT — 

emr  ■eiu|e**Hnnworked 
eiceediUihdfir 
AD.FkldiJilid^fibe 

X  AU_riridi_Vilid*liilie 

Yei 

- ^ 

"  No 

PriitEip.Ni, 

Piy_Rite, 

Hn.Worked, 

emr_iciii|c 

Htin  W«rked<B3S 

Yei 

Eip_Wcckl]r_Piy« 
Piy_Ritc*Hn.Wirked; 
PriitEip_Ni,Pi7_Ritt, 
Hn  Worked,' 
Eip.Weckly.Piy 

Ortftiit.Hn  >  Hn.Wifkid  • 

3S;  OfirtiBi.Piy  -  OTirtiBi_ 

bp.Wnkb.^  ■  (hy.ltit 
•35) + OT^c_Piy;  PAl 
Pq.liU,  In.Wirkid, 
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Nassi-Shneiderman  Notation 
For  DOWHILE  Loops 


Proceu.Stidcit.Kirolhieiti 

SetTitii  Feitbi  liriBedteieri 

M  Ml 

Set  to  Krt 

Set  Titil Jtideiti  .EinUei  ti  icri 

leidStideit  tceerd 

_ _ _ — _ _ 
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LECTURE  NUMBER:  034 

TQPICiS)  FOR  LECTURE: 

Introduction  to  Ada  and  I/O  in  Ada 


INSTRUCTIONAL  OBJECTIVES): 

1 .  To  understand  the  uniqueness  of  Ada. 

2.  To  learn  the  elementary  features  of  the  Ada  programming  language  and  how 
it  handles  input  and  output. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

You  will  begin  the  implementation  phase  of  the  second  project  soon.  This 
project  is  to  be  implemented  in  Ada.  In  previous  classes,  we  have  looked  at 
Ada  software  artifacts  through  program  reading. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Now  we  will  look  in  detail  at  Ada  in  order  to  prepare  for  the  implementation 
phase  of  the  second  project. 


CONTENTS: 

L340H1 

1 .  Discuss  the  general  characteristics  of  Ada  Although  it  was  built  for 
embedded  systems  ,  it  is  a  general  purpose  language. 

2.  It  is  assumed  that  students  are  already  proficient  in  a  standard 
strongly  typed  programming  language.  The  implementation  details  of 
Ada  will  be  covered  quiddy  to  enable  students  to  start  work  on  their 
project  implementation.  This  rapid  introduction  is  done  by  frequent 
references/comparisons  to  the  language  in  which  they  are  already 
proficient. 

3.  Standard  input  and  output  with  TextJO  L340H2 

a.  Ada  contains  no  input  and  output  standards;  instead,  Ada 
provides  a  general-purpose  package  called  TextJO  which 
contains  a  collection  of  subprograms,  types,  subtypes,  and 
exceptions  used  for  file  manipulation  and  input  and  output  to 
keyboard  and  monitor.  The  TextJO  package  provides  directly 
the  routines  needed  for  input  and  output  of  character  and  string 
data  types.  Included  in  TextJO  are  generic  packages  for  input 
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and  output  of  integers,  floating  point  numbeie,  fixed  point 
numbers,  and  enumeration  data  type.  There  are  Ada  I/O 
packages  for  manipulating  other  data  types  as  well. 

b.  L340H3  shows  the  basic  routines  provided  by  Ada  along  with 
their  equivalent  Pascal  statement. 

i  Get  is  analogous  to  Pascal's  Read.  Get.Line  however 
reads  strings  only  and  requires  a  second  parameter  into 
which  the  length  of  the  line  read  is  placed. 

ii  Similarly,  Put.Line  is  available  only  for  the  string  data 
type.  Put  needs  formatting  information  for  integers  and 
decimal  numbers.  Point  this  out  in  the  examples  shown. 
X  (in  fourth  example)  is  an  integer  and  Y  (in  fifth 
example)  is  of  type  float.  Point  out  also  that  Ada 
enables  you  to  specify  the  base  of  the  number  being 
printed. 

c.  L340H4 

Discuss  the  sample  program  shown. 

i.  Note  the  following:  "with"  and  "use"  are  parts  of  the 
"context  clause";  The  "use"  clause  cause  the  compile  to 
look  at  TextJO  for  commands;  so  that  one  need  only 
write  PUTC'Hello  world!");  rather  than 
TextJO.PUT("Hello  world"); 

ii.  The  "with"  clause  tells  the  compiler  that  the  procedure 
needs  the  help  of  another  package,  and  specifies  that 
package  name. 

d.  TextJO  also  provides  standard  input  and  output  for  text  files. 
L340H5  A  text  file  is  a  collection  of  characters  that  are 
organized  into  lines  and  pages  and  is  terminated  with  a  file 
terminator.  The  data  type  for  a  text  file,  as  provided  in 
TextJO,  is  RleJType.  There  are  two  file  modes  for  text  files: 
ln_file  for  reading  data  from  a  file  and  Out.Rle  for  writing  data 
to  a  file.  Every  text  file  must  be  specified  in  one  of  these  two 
modes. 

e.  TextJO  provides  several  routines  for  the  management  of  files 
including  Create,  Open,  Close,  Delete,  Reset,  End_of_Line, 
and  End_of_File.  Discuss  these  using  overheads  L340H6, 
L340H7,  L340H8. 
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f.  Exceptions  are  abnormal  conditions  that  oocur  at  nin  time. 
Discuss  some  of  the  commonly  used  exceptions  shown  on 
overheads  L340H9.  L34OH10. 

g.  Discuss  the  sample  program  illustrating  file  usage  is  shown  on 
overhead  L340H11. 


PROCEDURE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  this  lecture. 


vocabulary  introduced: 
TextJO 
text  file 
file  mode 


INSTRUCTIONAL  MATERIALS: 


overheads: 

L340H1 

L340H2 

L340H3 

L340H4 

L340H5 

L340H6 

L340H7 

L340H8 

L340H9 

L34OH10 

naodouts: 


Ada 

Standard  input  and  output  with  TextJO 
TextJO  Operations 
Sample  program  using  TextJO 
Standard  input  and  output  on  files 
File  management 
File  management(cont.) 

File  managementjcont.) 

Exceptions  provided  by  TextJO 
Exceptions  provided  by  TextJO(cont.) 


RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 

READING  ASSIGNMENTS: 

Benjamin  Chapters  1  (pp.  1-10) 


RELATED  READINGS: 
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Booch  Chapter  6  (pp.  69-60) 
Booch(2)  Chapter  4  (pp.  60-71) 
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Ada 


General-purpose 


Strongly  typed 


Block-structured 


Procedural 


Supports  concurrency,  exception  handling,  and 
low-level,  implementation-dependent  features 


Designed  to  support  software  engineering 
concepts 

Information  hiding 
Modularity 
Reusability 
Maintainability 
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Standard  Input  and  Output  with  TextJO 


TextJO  is  package  of  routines  provk  ^nput  and 
output  on  text  fiies,  keyboard,  and  monitor 


Directly  provides  routines  for  input  and  output  of 
character  and  string  types 


Provides  generic  packages  for: 
Integer  (Integer  JO) 

Float  (Float  JO) 

Fixed-point  (RxedJO) 
Enumeration  (EnumerationJO) 
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TextJO  Operations 


Get  (A): 

read  (A); 

Get_Line  (A,  Length); 

readin  (A); 

Put  (''hello''); 

write  ('hello'); 

Put  (X,2,10); 

write  (x:2); 

Put  (Y, 3,2,0); 

write  (y:6:2); 

Put_Line  ("hello"); 

writein  ('hello'); 

Skip_Line; 

readin; 

Skip_Line  (2); 

readin; 

readin; 

New_Line; 

writein; 

New_Line  (2); 

writein; 

writein; 
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Sample  Program  using  TextJO 


with  TextJO;  use  TextJO; 
procedure  POWER  is 

package  INTJO  is  new  IntegerJO  (integer); 
use  iNTJO; 

BASE,  COUNT,  EXPONENT,  PRODUCT  : 
integer; 
begin 

Put_Line  ("Piease  enter  the  base  vaiue"); 

Get  (BASE); 

Put_Line  ("Piease  enter  the  exponent  value"); 
Get  (EXPONENT); 

COUNT  :=  1 ; 

PRODUCT  :=  BASE; 
while  COUNT  <  EXPONENT  loop 
PRODUCT  :=  PRODUCT  *  BASE; 

COUNT  :=  COUNT  +  1 ; 
end  loop; 

Put  ("Base  = "); 

Put  (BASE); 

Put  ("  Exponent  = "); 

Put  (EXPONENT); 

Put  ("Product  = "); 

New_Line; 

Put  (PRODUCT); 
end  POWER; 
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standard  Input  and  Output  on  Files 


Text  file 

A  collection  of  characters  that  may  be 
organized  into  lines  and  pages  (using  line 
terminators  and  page  terminators).  The  end 
of  a  text  file  is  indicated  with  a  file  terminator. 

Supported  in  Text  JO 

Data  type  called  FileJType 


File  modes  available  for  text  files: 
ln_File  indicates  a  file  is  read  only 
Out_File  indicates  a  file  is  write  only 
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File  Management 


Create 

Opens  a  new  external  file  and  associates  an 
internal  file  with  it;  file  is  initiaiiy  empty 

Defauit  file  mode  is  Out_File 

Parameters:  1  -  fiie  identifier 

2  -  access  mode 

3  -  externai  fiie  name 


Exampie  of  use: 

Create  (Report_file,  Out_File, 
"a:\summary.rep"); 


Open 

Opens  an  existing  file  for  processing,  starting 
at  the  beginning  of  the  fiie 

No  defauit  fiie  mode 

If  the  external  file  specified  does  not  exist,  a 
Name_Error  exception  is  raised 

Open  (Source2,  ln_File, 

"a  :\prog1  Jones.pas") ; 
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File  Management  (cent.) 


Close 

Removes  the  association  of  the  Ada  file 
identifier  with  its  associated  external  file 

Close  (Source); 


Delete 

Deletes  the  external  file  associated  with  the 
given  Ada  file  identifier 

Delete  (Report_file); 


Reset 

Moves  back  to  the  beginning  of  the  fiie, 
possibiy  changing  the  file  mode,  and  allowing 
reading  or  writing  operations  to  resume  from 
the  beginning  of  the  file.  The  file  mode  is 
changed  only  if  a  new  mode  is  specified  as 
the  second  parameter. 

Reset  (Sourcel); 

Reset  (Source2,  Out_Flle); 
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File  Management  (cent.) 


Boolean  functions  to  test  for  the  current  position  in 
reading  input; 

End_of_Line  Returns  true  if  the  next 

component  is  a  line  terminator  or 
file  terminator:  otherwise,  returns 
false 

End_of_Line  (Sourcel); 


End_of_Page  Returns  true  if  the  next 

component  is  a  page  terminator 
or  file  terminator:  otherwise, 
returns  false 

End_of_Page  (Sourcel); 


End_of_File  Returns  true  if  the  next 

component  is  either  a  file 
terminator  or  the  three-component 
sequence  of  line  terminator,  page 
terminator,  file  terminator: 
otherwise,  returns  false 

End_of_File  (Sourcel); 
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Exceptions  Provided  by  TextJO 


Status_Error 


Mode_Error 


Name_Error 


Use  Error 


Attempt  to  use  a  file  that  has  not 
been  opened  or  to  open  a  file  that 
is  already  open 


Attempt  to  perform  an  input 
operation  on  a  file  of  mode 
Out_Fiie  or  to  perform  an  output 
operation  on  a  file  of  mode 

In  File 


Attempt  to  associate  an  internal 
file  with  an  external  file  if  an 
invalid  external  file  name  is 
specified 


Attempt  to  perform  some 
input/output  operation  on  an 
external  file  for  which 
implementation  does  not  allow 
that  operation 
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Exceptions  Provided  by  Text_IO  (cont.) 


Device  Error 


End  Error 


Data  Error 


Layout_Error 


A  problem  with  the  hardware, 
software,  or  media  providing 
input/output  services 


Attempt  to  read  past  end  of  an 
input  file 


Input  data  that  is  not  of  expected 
form 


Invalid  Text_IO  formatting 
operations 
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Sample  Program  using  Hies 


with  TextJO; 
use  TextJO: 

procedure  MAIN  is 

package  INTJO  is  new  IntegerJO  (integer); 
use  INT_IO; 

INPUT_FILE  :File_Type: 

NEXTJTEM  :  integer; 

begin 

open  (INPUT_FILE,  ln_File,  "a:\testresults.dat"): 

while  not  End_of_File  (INPUT_FILE)  loop 
Get  (INPUT_FILE,  NEXTJTEM); 

Put  ("Test  result  =  "); 

Put  (NEXTJTEM): 

New_Line: 
end  loop; 

Close  (INPUT_FILE): 
end  MAIN; 
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LECTURE  NUMBER:  035 


TOPJCCS)  FQR  LECTURE: 
Data  types  in  Ada 


INSTRUCTIONAL  QBJECTIVEfS): 

1 .  To  introduce  the  concept  of  a  compilation  unit. 

1.  To  learn  the  features  of  the  Ada  programming  language  concerning 
scalar  data  types. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 
(Learning  Label-  Today  we  are  going  to  learn  ...) 


CONTENTS: 

1.  Ada's  program  structure  L350H1 

a.  Comments  in  Ada  by  begin  with  a  double  hyphen  . 
Comments  terminate  at  the  end  of  a  line.  There  is  no  other 
comment  terminator. 

b.  Compilation  units  are  the  pieces  of  a  program  that  can  be 
compiled  separately.  Compilation  units  include  package 
specifications,  package  bodies,  subprogram  declarations,  and 
subprogram  bodies.  The  Ada  compiler  maintains  a  program 
library  with  the  needed  informatbn  about  the  compilation  units 
used  in  a  program.  These  compilation  units  can  be  specified 
in  the  context  clause.  Ada  can  use  this  information  to  provide 
consistency  checking  across  the  separate  compilation  units. 
The  main  program  does  not  have  any  parameters. 


2.  Ada  data  types  L350H2 

a.  Ada  provides  scalar  data  types  (discrete  and  real),  composite 
data  types  (arrays  and  records),  access  data  tyiMS,  private 
data  t^s,  subtypes  and  derived  types.  Today  we  are  only 
examining  the  scalar  data  types  of  Ada.  The  discrete  data 
types  to  be  examined  are  represented  internally  as  integer  (Ada 
provides  predefined  integer  types  Integer,  Natural,  Poeltive) 
and  enumeration  (Ada  provides  predefined  enumeration  types 
Ctiaracter  and  Boolean).  The  real  data  types  provided  by  Ada 
are  floating  point  (Float)  and  fixed  point.  For  each  of  these 
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data  types,  we  will  look  at  the  predefined  range  of  values  for 
Ada's  predefined  data  types,  user-defined  data  types, 
declaration  of  objects,  declaration  of  constants,  operations  and 
operators,  attributes,  and  input/output.  Universal  integers  and 
universal  reals  are  also  discussed.  Review  the  overheads. 
L350H12  is  an  exercise  to  use  in  class.  There  will  be 
constraint  errors  on  Pred(Monday).  Succ(Sunday)  and  Vai(7). 
L350H3.  L350H4.  L350H5,  L350H6.  L350H7.  L350H8. 
L350H9.  L35OH10.  L350H11.  L350H12,  L350H13,  L350H14 


PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 


INSTRUCTIONAL  MATERIALS: 

overheads: 

L350H1 

Ada's  program  structure 

L350H2 

Ada's  data  types 

L350H3 

Integer  data  type 

L350H4 

Named  numbers 

L350H5 

Real  numbers 

L350H6 

Formatting  numeric  output 

L350H7 

Arithmetic  operations 

L350H8 

Numeric  attributes 

L350H9 

Enumeration  data  type 

L35OH10 

Enumeration  I/O 

L350H1 1 

Attributes  for  enumeration  data  type 

L350H12 

Examples  of  enumeration  attributes 

L350H13 

Derived  type  declarations 

L350H14 

Subtype  declarations 

handouts: 
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RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 


READING  ASSIGNMENTS: 

Benjamin  Chapters  2-3  (pp.  11  >28) 

RELATED  READINGS: 

Booch  Chapter  8  (pp.  103*115) 
Booch(2)  Chapter  6  (pp.  93  - 105) 
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Ada's  Program  Structura 


Comments 

Begins  with  a  doubie  hyphen and  extends 
to  the  end  of  the  line 


Compilation  units 

Pieces  of  a  program  that  can  be  compiled 
separately 

May  be  package  specification,  package  body, 
subprogram  declaration,  or  subprogram  body 

Ada  keeps  a  library  ("program  library")  with 
information  about  the  compilation  units  used 
in  a  program;  thus,  Ada  can  check  for 
consistency  between  the  compilation  units 

Context  clause 


Main  programs 

Only  parameterless  procedures 
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Ada's  Data  Types 


Specify  a  set  of  values  and  a  set  of  operations 
applicable  to  these  values 


Provided  by  Ada: 

Scalar 

Discrete 

Integer  (Integer,  Natural,  Positive) 
Enumeration 

Character  (Character) 

Boolean  (Boolean) 

Real 

Floating  point  (Float) 

Fixed  point 
Composite 
Arrays 

Constrained 
Unconstrained 
Strings  (String) 

Records 

Access  (i.e.,  pointers) 

Subtype  and  derived  types 


5 


L3SOH2 


Integer  Data  Type 


Predefined  range  of  values 

lnteger’first..lnteger’last 


Subtypes  of  integers 
Predefined  subtypes 

Natural  integer  >=  0 
subtype  NATURAL  is  integer 
range  0..integer'iast; 

Positive  integer  >=  1 
subtype  Positive  is  integer 
range  1  ..integer'iast; 

User-defined  subtypes 

type  INDEX  is  range  1  ..50; 


Deciaring  integers 

NUM  :  Integer; 

INCREMENT  :  Integer  :=  1; 

"  constant  must  be  initialized 

DECREMENT  :  constant  Integer  :s  1 ; 

A,B>C  :  integer  :s  0; 

X,Y^  :  integer  :s  2,3,4;  ~  illegal 
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Named  Numbers 


A  constant  that  is  declared  without  assuming  a 
type  and  can  be  used  with  all  numeric  types. 


TENS  :  constant  :s  10; 
HUNDREDS  :  constant  :=  TENS  *  10; 
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Real  Numbers 


Floating  Point 
Relative  error 

Predefined  range  of  values 

Float'first..Float'last 

User-defined  subtypes 
type  CELSIUS  Is  digits  3; 
type  DISTANCE  is  digits  3  range  -50..50; 

Deciaring  floats 

ROOM_RATE  :  Hoat; 

PI  :  constant  Float  :=  3.1456; 


Fixed  Point 

Must  define  accuracy  specification  (absolute 
error)  and  range  in  deciaration 

type  RATE  is  delta  0.001  range  7.0..12.0; 
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Formatting  Numeric  Output 


For  integers: 

Put  (iNTEGER_VALUE,  width_of_fieid); 

Put  (X,  3);  -  outputs _ ^3 

Fid  rt  justified 

width 


For  reals: 

Put  (REAL_VALUE,  fore,  aft,  exp); 

fore=number  of  digits  before  decimal  point 
aftsnumber  of  digits  after  decimal  point 
exp=the  base,  e.g.  Debase  1 0 

Put  (2.573,  3,  2,  0);  --  output _ ^2,57 
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Arithmetic  Operations 


Unary  Arithmetic  Operations 


Operation  Operator 

absoiute  value  abs 

unary  plus  + 

unary  minus 

Binary  Arithmetic  Operations 

Operation  Operator 

exponentiation  ** 

multiplication  * 

division  / 

modulus  mod 

remainder  rem 

addition  + 

subtraction 

Relational  Operators 

Operation  Operator 

equal  s 

not  equal  /s 

less  than  < 

less  than  or  equal  <= 

greater  than  > 

greater  than  or  equal  >s 
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Numeric  Attributes 


Attribute 

gives  information  about  particular  properties  of 
a  type 


Attributes  for  integers: 

First  first  value  in  integer's  range 
Last  last  value  in  integer's  range 

put(integer'first);  prints  the  first  integer 


Attributes  for  floats: 

First  first  value  in  float's  range 
Last  last  value  in  float's  range 
Digits  number  of  significant  figures 
Smaii  smallest  positive  float  number 
Large  largest  positive  float  number 
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Enumeration  Data  Type 


Subtypes  of  enumeration  data  types 
Predefined  subtypes 
Boolean  false,  true 
Character  ASCII  character  set 

User-defined  subtypes 

type  DAY  is  (MONDAY,  TUESDAY, 
WEDNESDAY,  THURSDAY,  FRIDAY, 
SATURDAY,  SUNDAY); 

Declaring  enumeration  data  types 

TODAY  :  DAY; 

TOMORROW  :  DAY  :s  TUESDAY; 
FIRST_DAY  :  constant  DAY  :=  MONDAY; 

Operators 

Relational  (s,  /s,  <,  <=,  >,  >=) 

Membership  (in,  not  in) 

Boolean  operators  (and,  or,  xor,  not) 
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Enumeration  I/O 


Remember  that  TextJO  provides  a  generic 
package  for  enumeration  input  and  output 


package  DAYJO  is  new  EnumerationJO 

(DAY); 

use  DAYJO; 


package  BOOLEANJO  is 

new  ENUMERATIONJO  (Boolean); 
use  BOOLEANJO; 
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Attributes  for  Enumeration  Data  Type 


First  first  value  in  enumeration  data  type 

Last  last  value  in  enumeration  data  type 

Pred  predecessor  of  argument 
constraint  error  on  first 

Succ  successor  of  argument 

constraint  error  on  last 

Pos  position  in  list  (count  starts  at  0) 

Val  value  associated  with  argument  which  is 
the  position  in  the  list 
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Examples  of  Enumeration  Attributes 


type  DAY  is 

(MONDAY, TUESDAY, WEDNESDAY, 
THURSDAY,  FRIDAY,  SATURDAY,  SUNDAY); 

DAY'First 

DAY'Last 

DAY'Pred  (TUESDAY) 

DAY'Pred  (MONDAY) 

DAY'Succ  (TUESDAY) 

DAY'Succ  (SUNDAY) 

DAY'Pos  (TUESDAY) 

DAY'Val  (2) 

DAY'Val  (7) 
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Derived  Type  Declarations 


defines  a  new  and  distinct  type  which  inherits  all 
the  features  of  the  parent  type 

new  type  is  not  compatible  with  parent  type 


with  TextJO;  use  TextJO; 
procedure  DERIVED.DEMO  is 
type  LENGTH  is  new  Integer; 
type  AREA  is  new  Integer; 
package  AREAJO  is  new  IntegerJO 
(AREA); 
use  AREAJO; 

LI,  L2  :  LENGTH  :s  3; 

A  :  AREA; 

function  (X,  Y  :  LENGTH)  return  AREA 
is 

begin 

return  AREA  (Integer  (X)  *  Integer  (Y)); 
end; 

begin 

A  :s  LI  *  L2; 

-  The  will  only  work  if  LI  and  L2 
--  match  the  data  type 
Put  (A); 

end  DERIVED  DEMO; 
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Subtype  Declarations 


Does  not  define  a  new  (i.e.,  distinct)  type  but 
promotes  readabiiity 

Provides  a  new  name  for  another  (potentiaiiy 
constrained)  data  type 

inherits  ali  the  properties  of  base  type 


type  DAY  is 

(MONDAY,  TUESDAY,  WEDNESDAY, 
THURSDAY,  FRIDAY,  SATURDAY,  SUNDAY); 

subtype  WEEKDAY  is  DAY 
range  MONDAY-FRiDAY; 
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UECTURE  NUMBER:  036 


TOPtCfS^  FOR  LECTURE: 
Statements  in  Ada 


INSTRUCTIONAL  OBJECTIVeS): 

1 .  To  learn  the  features  of  several  Ada  statements. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 
(Learning  Label-  Today  we  are  going  to  learn  ...) 


CONTENTS: 

1.  Ada  statements  L360H1 

a.  A  statement  is  a  program  construct  defining  an  action  to  be 
performed  during  execution.  There  are  two  types  of  statements 
in  Ada:  simple  (e.g.,  assignment  statement)  and  compound 
(e.g.,  loop,  if,  case).  A  compound  statement  is  a  control 
structure  that  surrounds  other  statements  whereas  a  simple 
statement  does  not.  Every  statement  is  terminated  by  a 
semicolon;  in  fact,  the  semicolon  is  considered  part  of  the 
statement  and  not  a  statement  separator. 

L360H2 

b.  The  Ada  statements  examined  are  assignment  statement,  null 
statement,  block  statement,  iteration  statements  (basic  loop,  for 
loop,  while  loop),  and  selection  statements  Of.  case)  .  Discuss 
examples  of  each  of  these.  Discuss  only  the  unique  features 
of  Ada  are  discussed. 

c.  The  null  statement  uses  the  reserved  word  null  to  show  a 
statement  that  performs  no  action.  This  type  of  statement  is 
commonly  used  in  case  statements  and  exception  handlers. 

d.  The  block  statement  encapsulates  a  collection  of  declarations 
and  statements  that  are  logically  related.  The  scope  of  the 
declarations  and  exceptions  within  a  block  is  the  block  itself. 
The  block  statement  is  commonly  used  for  several  purposes. 
It  ensures  that  the  deciaration(s)  within  the  block  are  not  used 
inappropriately  by  other  parts  of  the  program.  It  documents  the 
extent  of  the  declaration(s),  and  it  provides  an  exception 
handier  environment.  The  declaration  part  and  excejstion 
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handler  part  are  optional. 

e.  The  simplest  loop  in  Ada  provides  for  an  infinKe  loop  (i.e.,  one 
that  loops  forever)  L360H3.  This  type  of  loop  is  useful  for 
activities  such  as  data*sampling  that  must  continue  forever 
once  initiated.  The  loop  can  be  constructed  to  end  by  inckjding 
one  or  more  exit  statements  within  the  loop.  An  unconditional 
or  conditional  exit  statement  may  be  used.  L360H4,  L360H5, 
L360H6.  L360H7 


f.  Discuss  the  remaining  Ada  statements,  L360H4-L360H7 

PROCEDURE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  this  lecture. 


vocabulary  introduced: 


INSTRUCTIONAL  MATERIALS: 
overheads: 

L360H1  Ada  statements 

L360H2  Ada  statements 

L360H3  Iteration  statements  -  basic  loop 
L360H4  Iteration  statements  •  for  loop 
L360H5  Iteration  statements  •  while  loop 
L360H6  Selection  statements  >  if  statement 

L360H7  Selection  statements  -  case  statement 


tiaodfiuis: 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

READING  ASSIGNMENTS: 

Benjamin  Chapters  4  (pp.  29-37) 

RELATED  REAPINfiS: 

Booch  Chapter  11  (pp.  187-197) 
Booch(2)  Chapter  9  (pp.  181-190) 
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Ada  Statements 


A  program  construct  defining  an  action  to  be 
performed  during  execution 


Terminated  by  semicolon 

Two  types 
Simpie 

Compound 
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L360H1 


Ada  Statements 


Assignment  statement 
Null  statement 

Statement  that  performs  no  action 

when  others  a>  null; 


Block  statement 

Encapsulates  a  collection  of  declarations  and 
statements  that  are  logically  related 

Scope  of  identifiers  and  exceptions  for  block 
is  the  region  of  program  text  that  begins  with 
the  declaration  and  extends  to  the  end  of  the 
block 

declare 

TEMP  :  Integer  :s  NUM_1 ; 
begin 

NUMJ  NUM  2; 

NUM_2  :s  TEMP; 

-  exception  handlers  can  go  here 
end; 
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L360H2 


Iteration  Statements 
Basic  Loop 


Staictured  to  loop  forever  (one  entry,  no  exit) 

loop 

-  statements 
end  loop; 


To  leave  such  a  loop,  use  the  exit  statement 
loop 

~  statements 
exit; 

-  statements 
end  loop; 


COUNT  :s  1 ; 
loop 

COUNT  :s  COUNT  +  1 ; 

~  statements 
exit  when  (COUNT  s  10); 
end  loop; 
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Iteration  Statements 
For  Loop 


(X  is  implicitly  declared  with  the  for*) 

for  X  in  1..3  loop 
-  statements 
end  loop; 


for  INDEX  in  1..USERJNPUT_LIMIT  loop 
-  statements 

NAME  :s  AN_ARRAY  (INDEX); 

--  statements 
end  loop; 


for  CH  in  'A'..T  ioop 
put  (CH); 
end  ioop; 


for  CH  in  reverse  'A\.T  ioop 
put  (CH); 
end  ioop; 
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L360H4 


Iteration  Statements 
While  Loop 


Sequence  of  statements  is  repeated  as  long  as 
condition  in  while  condition  is  true 

while  not  end_of_file  (SOURCE2)  loop 
get  (SOURCE2,  A); 

-  statements 
end  loop; 


COUNT  :=  1 ; 

while  (COUNT  Is  10)  loop 
COUNT  :s  COUNT  +  1 ; 
•>  statements 
end  loop; 


SUM  :s  0; 

Get  (A_VALUE); 
while  (A_VALUE  /=  0)  loop 
SUM  :s  SUM  +  A_VALUE; 
Get  (A_VALUE); 
end  loop; 


7 


L360H5 


'  -  .  j..  ,11. 1,  .11 

Selection  Statements 
If  Statement 


If  VAL_1  >  VAL_2  then 
MAX  :s  VAL_1; 

Putjine  ("First  value  is  largest"); 
end  if; 

if  BALANCE  <S  0.0  then 
SERVICE_CHARGE  :s  10.00; 
elsif  BALANCE  <  300.00  then 
SERVICE.CHARGE  :s  3.00; 
else 

SERVICE_CHARGE  :s  1.00; 
end  if; 

if  BALANCE  >  0.0  then 
if  BALANCE  <  300.00  then 
SERViCE.CHARGE  :s  3.00; 
eise 

SERViCE_CHARGE  :s  1.00; 
end  if; 
eise 

SERViCE_CHARGE  :s  10.00; 
end  if; 
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Selection  Statements 
Case  Statement 


case  SCORE  is 

when  85..100  s>  GRADE  :s  'A'; 
when75..84  s>  GRADE  :s 'B'; 
when60..74  s>  GRADE  :s 'C; 
when  0..59  b>  GRADE  :s  'P; 
when  others  s>  null; 
end  case; 

case  GRADE  is 

when  'A'  |  'B*  |  'C  =>  putjine  (’pass'); 
when  'P  B>  putjine  ('fail'); 
when  others  s>  putjine  ('invalid  score'); 
end  case; 

case  SELECTION.CODE  is 
when  'W'  s> 

BALANCE  :b  BALANCE  -  AMOUNT; 
Put_Line  ("Removing  cash"); 
when  'D'  s> 

BALANCE  :b  BALANCE  +  AMOUNT; 
Put_Line  ("Adding  cash"); 
when  others  s>  Put_Line  ("Invalid  key"); 
end  case; 
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LECTURE  NUMBER:  037 


TQPiClS)  FQR  LECTUBE: 

Structured  data  types  in  Ada 


INSTRUCTIONAL  QBJECTIVEfSV. 

1 .  To  learn  the  features  of  the  Ada's  stmctured  data  types. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

We  have  already  discussed  Ada's  scalar  data  types  (integers,  etc). 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  are  going  to  look  at  Ada's  composite  data  types. 

CONTENTS: 

1.  Ada  data  structures  L370H1 

a.  Arrays  are  composite  data  structures  which  contain  a  collection 
of  components  of  the  same  data  type  L370H2.  Ada  provides 
two  types  of  arrays:  constrained  and  unconstrained. 
Constrained  arrays  have  their  tower  and  upper  bounds  for  their 
indices  defined  in  the  type  declaration  L370H3. 
Unconstrained  arrays  define  their  index  type  in  the  declaration 
but  do  not  define  their  tower  and  upper  bounds  for  their  indices. 
These  bounds  are  defined  in  the  object  declaration  L370H4. 
This  feature  aliov^  objects  of  different  sizes  to  be  created  from 
the  same  data  type;  we  have  seen  in  a  previous  class  how  this 
language  feature  is  helpful  in  reusability.  The  operations  and 
I/O  for  arrays  are  the  same  as  for  Pascal.  L370H5.  Ada 
provides  attributes  for  arrays  (Rrst,  Last,  Range,  Length) 
Use  the  definitions  of  L370H6  and  work  through  the  exercise 
on  L370H7. 

b.  String  data  type  is  a  predefined  unconstrained  array  of  type 
Character.  At  object  declaration,  the  size  of  the  string  is 
specified.  The  I/O  provided  by  TaxtJO  was  (tscussed 
previously.  Ada  provides  the  attributes  Value  and  Image  for 
strings.  L370H8,  L370H9,  L37OH10 

c.  Record  data  types  are  composite  data  structures  which  contain 
a  collection  of  components  of  possibly  different  data  types. 
Records  are  the  same  in  Ada  as  in  Pascal  except  for  the  ability 
to  initialize  values  at  type  declaration  and  object  declaration. 
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Variant  records  and  discriminants  are  covered  in  the  textbook 
but  wiii  not  be  discussed  in  class.  L370H11.  L370H12 


P-BQCEPU.RE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  tNs  lecture. 

xQcabulary  introduced: 


INSTRUCTIONAL  MATERIALS: 

gyertiaads: 

L370H1 

Ada  data  types 

L370H2 

Array  data  types 

L370H3 

Constrained  arrays 

L370H4 

Unconstrained  arrays 

L370H5 

Arrays 

L370H6 

Array  attributes 

L370H7 

Examples  of  array  attributes 

L370H8 

String  data  type 

L370H9 

String  data  type  -  operations  and  I/O 

L37OH10 

String  attributes 

L370H11 

Record  data  type 

L370H12 

Record  data  type  -  accessing,  operations,  I/O 

liandgvtg: 

BELATED  LEARNING  ACTIViTiES: 
(labs  and  exercises) 


READING  ASSIGNMENTS: 

Benjamin  Chapter  5  (pp.  39-50) 


BELATED  READINGS: 

Booch  Chapter  8  (pp.  115-124) 
Booch(2)  Chapter  6  (pp.  105-115) 
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Ada  Data  Typea 


Scalar 

Discrete 

Integer  (Integer,  Natural,  Positive) 
Enumeration 

Character  (Character) 

Boolean  (Boolean) 

Real 

Floating  point  (Float) 

Fixed  point 

Composite 

Arrays 

Constrained 
Unconstrained 
Strings  (String) 

Records 

Access  (i.e.,  pointers) 

Private 

Subtype  and  derived  types 
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L370H1 


Array  Data  Typea 


Data  structure  consisting  of  a  linear  sequence  of 
components  of  the  same  data  type 


Two  types  of  arrays; 

Constrained 

The  lower  and  upper  bounds  for  each 
array  index  are  defined  at  type  declaration 


Unconstrained 

The  lower  and  upper  bounds  for  each 
array  index  are  not  defined  at  type 
declaration  but  are  defined  at  object 
declaration 
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Constrained  Arrays 


Type  declarations 

type  COST  is  array  (1  ..8)  of  Fioat; 
type  MATRIX  is  array  (1..3, 1..3)  of  Integer; 

Object  declarations 

COAT_COSTS  :  COST; 

DRESS_COSTS  :  COST  :=  (90.0,  80.0, 

70.0,  60.0,  97.5,  81.0,  72.0,  85.0); 

DRESS2_COSTS  :  constant  COST  :=  (90.0, 
80.0,  70.0,  60.0,  97.5,  81.0,  72.0,  85.0); 

JEAN.COSTS  :  COST  :s  (1  =>  30.0, 

2  =>  19.0,  3  =>  15.50,  4  =>  56.0, 

5  a>  27.50,  others  b>  28.0); 

~  called  anonymous  array  object 

NEW_COSTS  :  array  (1..8)  of  Fioat; 

MATRIXJ,  MATRiX_2  :  MATRIX; 
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UnconMrained  Arrays 


Type  declarations 

type  VECTORJTYPE  is  array 
(Integer  range  o)  of  Integer; 

type  MATRIX_TYPE  is  array 

(Positive  range  o,  Positive  range  o) 
of  Integer; 

Object  declarations 

VECT0R1  :  VECTOR_TYPE  (1..30); 
VECT0R2  :  VECTORJTYPE  (1..10); 
MATRIX1  :  MATRIX_TYPE  (1..3, 1..10); 
MATRIX2  :  MATRIX_TYPE  (1..4, 1..6); 


6 


L370H4 


Arrays 


i.  p  ■ 


Array  I/O 

By  component  data  type 

Accessing  arrays 
By  component 

COAT_COSTS  (2)  :=  124.50; 

Put  (COAT_COSTS  (3)); 

As  whole 

Can  use  :s,  s,  /= 

Must  be  same  data  type 

MATRIX_1  :s  MATRIX_2; 

Relational  operators  <,  <s,  >,  and  >s  may 
be  applied  to  one  dimensionai  arrays 
whose  elements  are  of  a  discrete  type 

By  slice 

Accessing  consecutive  components  of  an 
array 

MATRIXJ  (1..3)  :s  MATRIX_2  (4..6); 
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L370H5 


Array  Attributes 


First 

returns  lower  bound  of  first  array 
index 

First(N) 

returns  lower  bound  of  Nth  array 
index 

Last 

returns  upper  bound  of  last  array 
index 

Ust(N) 

returns  upper  bound  of  Nth  array 
index 

Range 

Range(N) 

returns  range  of  first  array  index 

Length 

Length(N) 

returns  number  of  eiements  in  first 
index  range 
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L370H6 


Examples  of  Array  Attributes 


type  MATRIX.TYPE  is  array  (1..3,  0..30)  of 
Integer; 

MATRIX  :  MATRIX_TYPE; 

MATRIX_TYPETirst  (1) 

MATRIX_TYPE'First  (2) 

MATRIX_TYPE'Flrst 
MATRIX'Last  (1) 

MATRIX'Last  (2) 

MATRIX_TYPE'Range  (1) 
MATRlX.TYPE’Range  (2) 

MATRIX'Length 
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L370H7 


string  Data  Type 


type  STRING  is  array  (Positive  range  o) 
of  Character; 


Object  declarations 

FILE_NAME  :  String  (1..30); 

ERR_MSG  :  constant  String 

:s  "error  -  file  not  found"); 

LINE  :  String  (1  ..80)  (others  s>  ""); 
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L370H8 


string  Data  Type 


String  operations 

Relationai  operators  (=,  /=,  <,  <=,  >,  >s) 
Assignment  (:s) 

Concatenation  (&) 


String  i/0 

Piit_Line  (Hem  :  in  String); 

Put  (Item  :  in  String); 

Get.Line  (Item  :  out  String; 
Last :  out  Natural); 

Get_Line  (Hem  :  out  String); 


11 


L370H9 


string  Attributes 


Value  function  that  maps  the  value  of  String 

into  the  corresponding  value  of  the 
discrete  type 


X  :  integer  :=  Integer'Value  ("1000"); 


image  function  that  maps  values  of  integer 
or  enumeration  type  into  an 
expression  of  type  String 


ONE_THOUSAND  :  String  (1..4) 
:s  Integer'Image  (X); 
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L37OH10 


Record  Data  Type 


Data  structure  consisting  of  a  collection  of 
components  of  the  possibly  different  data  types 

Type  declarations 

type  NAME_TYPE  is 
record 

LAST_NAME  :  String  (1  ..20); 

FiRST_NAME  :  String  (1..20); 

MiDDLEJNiTiAL :  Character; 
end  record; 

Object  declarations 

MY_NAME  :  NAME_TYPE; 

YOUR.NAME  :  NAME.TYPE  := 
(MiDDLEJNiTiAL  => ' 
others  =>  "  ”); 

HiS.NAME  :  NAME_TYPE  :s 
("Appleseediess  ”, 

"Johnny  ",  'P'); 
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Record  Data  Type 


Accessing  records 

MY_NAME.MIDDLEJNmAL  :s  T; 


Operations  on  records 
Component  seiection 


Record  i/0 

By  component  only 
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Access(poiiiter)  data  types  in  Ada 


INSTRUCTIONAL  OBJECTlVEfSl: 

1 .  To  learn  the  features  of  Ada's  access  data  types. 


SET  WARM:,UP: 

(How  Involve  learner:  recall,  review,  relate) 

We  have  already  discussed  scalar  and  composite  data  types. 
(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we'll  discuss  access,  or  pointer  data  types. 


CQNTEMTS: 

1 .  Ada  access  data  types  L380H1 

a.  The  access  data  type  (often  called  pointer  data  type)  enables 
the  dynamic  creation  of  objects  during  the  execution  of  a 
program. 

L380H2 

b.  There  are  three  steps  to  using  access  data  types.  Rrst,  the 
access  type  and  obj^s  of  that  type  must  be  declared.  When 
an  object  of  an  access  data  t]^  is  created,  the  object  is 
automatically  initialized  to  the  value  null.  Here  B1 ,  B2,  and  B3 
are  initialized  to  null.  This  is  the  only  case  in  which  Ada 
defines  an  implicit  default  value. 

Second,  objects  of  the  access  type  are  dynamically  allocated. 
Using  the  allocator  new  in  an  assignment  statement 
dynamically  allocates  the  objects  of  an  access  type.  The 
allocation  process  also  allows  for  the  initialization  of  values 
either  by  positional  or  named  notation. 

Third,  allocated  objects  can  be  referenced  at  execution  time. 

L380H3 

c.  Access  data  types  can  be  compared  using  the  relational 
operators  •  or  /«.  This  is  valid  only  if  they  are  of  the  same 
t^.Ada  also  provides  a  notation  .all  which  refers  to  all  the 
values  of  an  access  data  type  (e.g.,  all  the  fields  of  the  record 
type  if  the  access  data  type  pointed  to  a  record). 
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L380H4 

d.  Illustrate  pointers  through  the  linked  list  implementation  of  a 
tree  as  shown  in  L380H4. 


PRQCEDU.BE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  this  lecture. 


vocabulary  introduced: 


INSTRUCTIONAL  MATERIALS: 

gvertiflads: 

L380H1  Ada  data  types 

L380H2  Steps  to  using  access  types  in  Ada 

L380H3  Operations  on  access  t^s 

L380H4  Example  of  linked  list 


handouts: 


BELMEP  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  028  •  Detailed  design  review  presentation 

READING  ASSIGNMENTS: 

Benjamin  Chapter  7  (pp.  63-72) 


RELATED  REAPIN6S: 

Booch  Chapter  8  (pp.  124-129) 
Booch(2)  Chapter  6  (pp.  115-121) 
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Ada  Data  Types 


Scalar 

Discrete 

Integer  (Integer,  Natural,  Positive) 
Enumeration 

Character  (Character) 

Boolean  (Boolean) 

Real 

Floating  point  (Float) 

Fixed  point 

Composite 

Arrays 

Constrained 
Unconstrained 
Strings  (String) 

Records 

Access  (i.e.,  pointers) 

Private 

Subtype  and  derived  types 
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Steps  to  Using  Access  Types  in  Ada 


1 .  Declare  access  type  and  objects  of  that  type. 

type  BUFFER  is 
record 

MESSAGE  :  String  (1..10); 

PRiORiTY  :  integer; 
end  record; 

type  BUFFER_PTR  is  access  BUFFER; 

B1,  B2,  B3  :BUFFER_PTR; 

2.  Dynamically  allocate  objects  of  the  access 
type. 

B1  new  BUFFER; 

B2  :=  new  BUFFER'(MESSAGE  =>  ’•**********'•, 

PRiORiTY  =>  2); 

3.  Work  with  aliocated  objects. 

B1  :s  nuii; 

B1. MESSAGE  :=  "Error  -  PI"; 

B1  .PRiORiTY  10; 

B2  :=  B1 ; 
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Operations  on  Access  Types 


Relational  operators  (s,  /=) 


Assignment  (:s) 


.all  notation 


Example  of  Linked  List 


type  NODE; 

type  TREE  is  access  NODE; 
type  NODE  is 
record 

LEFT  :TREE; 

VALUE  :  string  (1.. 5); 
RIGHT  :TREE; 
end  record; 

ROOT  :TREE; 

TEMP  :TREE; 

PTR  :TREE; 

ROOT  new  NODE; 
ROOT.VALUE  :s  "NODE1"; 
TEMP  :=  new  NODE; 

TEMP. VALUE  :s  "NODE2”; 
ROOT.LEFT  :s  TEMP; 

TEMP  :=  new  NODE; 
TEMP.VALUE  "NODES"; 
PTR  :=  ROOT.LEFT; 
PTR.RIGHT  :=  TEMP; 
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LECTURE  NUMBER:  039 


TQPIC(S)  PQR  LECIUBE: 

Procedures,  functions,  and  packages  in  Ada 


INSTRUCTIONAL  QBJECTIVEfS^: 

1 .  To  learn  the  features  of  the  Ada  programming  language  concerning 
procetKjres,  functions,  and  packages. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

In  other  lectures  we  have  looked  at  using  Ada  specifications  in  high 
level  design.  The  implementation  details  and  the  special  capabilities 
of  Ada,  such  as  overloading,  were  not  discussed. 

(Learning  Label*  Today  we  are  going  to  learn  ...) 

Today  we  shall  revisit  Ada's  packages,  functions,  and  procedures 
examining  the  details  needed  to  implement  these  language  structures.. 


CONIENIS: 

1.  Ada  subprograms  L390H1 

a.  As  in  other  programming  languages,  procedures  and  functions 
are  provided  in  Ada  as  fundamentai  tools  for  designing  and 
building  modular  programs.  Procedures  are  used  to  execute 
a  group  of  statements,  and  functions  are  used  to  determine 
and  return  a  value  that  is  used  in  an  expression. 

b.  Ada  allows  for  procedures  and  functions  to  have  a  specification 
part  and  a  body  or  implementation  part  L390H2.  The 
specification  part  is  the  interface  information  and  may  be 
compiled  in  a  file  separate  from  the  body.  This  separate 
compilation  feature  allows  the  subprogram  to  be  used  by  other 
compilation  units  without  the  implementation  details  in  the 
subprogram  body  being  completed.  Also  if  changes  are  later 
made  to  the  implementation  details,  there  is  no  need  to 
recompile  the  other  compilation  units  which  use  this 
subprogram. 

c.  Ada  provides  three  parameter  modes  L390H3.  The  in  mode 
allows  the  parameter  to  act  as  a  local  constant  within  the 
subprogram,  the  out  mode  allows  the  parameter  to  be 
assigned  a  value  by  the  subprogram,  and  the  In  out  mode 
allows  the  formal  parameter  to  be  initialized  to  the  value  of  the 
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actual  parameter  and  then  another  value  to  be  assigned  to  the 
parameter.  The  In  mode  is  the  default  parameter  mode. 


d.  For  In  parameters  only  L390H4,  a  default  value  may  be 
specified  in  the  formal  parameter  list,  and  then  the 
corresponding  actual  parameter  may  be  omitted.  If  the  default 
parameter  is  not  the  last  parameter  in  the  formal  parameter  list, 
named  notation  must  be  used  to  specify  any  remaining  actual 
parameters  in  the  procedure  call. 

e.  Ada  provides  two  types  of  parameter  association  L390H5.  in 
positional  notation,  which  is  the  type  commonly  used  in  other 
programming  languages,  the  order  of  the  actual  parameters 
must  match  the  order  of  the  formal  parameters.  In  named 
notation,  the  name  of  the  formal  parameter  is  associated  with 
the  actual  parameter  so  that  the  order  of  the  actual  parameters 
does  not  matter.  Additionally,  once  named  notation  is  used  in 
a  list,  it  must  be  used  for  the  remaining  parameters  in  the  list. 

f.  The  return  statement  can  be  used  in  both  procedures  and 
functions  to  terminate  the  subprogram  and  transfer  control  back 
to  the  calling  routine  L390H6.  In  a  function,  the  value  to  be 
returned  is  also  indicated  in  the  return  statement.  L390H8 
There  can  be  one  or  more  return  statements  in  any 
subprogram,  but  there  must  be  at  least  one  in  a  function.  A 
complete  example  showing  the  declaration,  body,  and 
invocation  of  a  procedure  and  function  are  shown  on  L390H7 
and  L390H8. 

g.  Overloading  is  the  use  of  the  same  name  or  operation  symbol 
for  different  entities  whose  scope  overlap.  They  are  said  to  be 
overloaded  provided  that  there  is  no  ambiguity.  Overloading 
can  be  used  for  subprogram  identifiers  as  well  as  operators, 
task  entry  identifiers,  and  enumeration  literals  L390H9.  The 
compiler  distinguishes  the  correct  intended  function  by  the 
parameters  passed  or  by  the  context  of  an  overloaded  name. 
Therefore,  for  all  overloaded  subprograms,  some  aspect  of  the 
subprogram  profile  (the  parameter  order,  number,  or  type  or 
the  returned  data  type  on  a  function)  must  be  unique  from 
other  subprograms  with  the  same  name.  If  some  ambiguous 
reference  is  made,  explicit  resolution  of  the  conflict  can  be 
made  through  named  parameter  association  or  a  qualified 
expression  L39OH10. 

h.  Discuss  the  scope  and  visibility  rules  L390H1 1 
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2.  Ada  packages  L390H12 

a. 

Ada  packages  v«re  introduced  in  an  earlier  class.  We  saw 
that  packa^  provide  a  mechanism  for  organizing  large  or 
complicated  programs. 

b. 

Private  and  limited  pri^te  data  types  can  be  declared  in  a 
package  specification  L390H13.  These  data  types  allow  the 
name  of  the  identifier  to  be  visible  but  the  implementation 
details  of  the  data  types  to  be  hidden.  These  data  types  are 
used  to  restrict  the  o^rations  available  for  certain  data  types. 

L390H14.  L390H15 

PROCEDURE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  diief  media  for  this  lecture. 

vocabulary  introduced: 
parameter  modes 
private  data  type 
limited  private  data  type 

INSTRUCTIONAL  MATERIALS: 

overheads: 

L390H1 

Ada  program  units 

L390H2 

Ada  procedures  and  functions 

L390H3 

Parameter  modes 

L390H4 

Default  parameter  values 

L390H5 

Parameter  association 

L390H6 

Return  statement 

L390H7 

Procedure 

L390H8 

Function 

L390H9 

Overloading 

L39OH10 

Explicit  resolution  with  overloading 

L390H11 

Scope  and  visibility  rules 

L390H12 

Packages 

L390M13 

Private  and  limited  private  data  types 

L390H14 

Private  data  type 

L390H15 

Limited  private  data  type 

haodfiuls: 

RELATED  LEARNING  ACTIVITJES: 

(labs  and  exercises) 

Lab  029  •  Feedback  on  detailed  design 

3  Lecture  039 

Benjamin  Chapter  6  and  8  (pp.  51-82  and  73-78) 


Booch  Chapter  13  (pp.  218-241) 
Booch(2)  Chapter  11  (pp.  218-240) 
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Ada  Program  Units 


Procedures  and  functions 


Packages 


Tasks 
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Ada  Procedures  and  Functions 


Procedure 

Used  to  execute  a  group  of  statements 


Function 

Used  to  determine  and  return  a  value  that  is 
used  in  an  expression 


Each  has  a  specification  (interface  information) 
and  body  (implementation  details) 

Permits  a  subprogram  name  and  parameter 
requirements  to  be  availabie  to  other 
compilation  units  separate  from  the 
subprogram  body 
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Parameter  Modea 


-TTT- 


Indicates  the  flow  of  the  data  between  the  oaller 
and  the  called  unit 

3  types  of  parameter  mode: 

1.  in 

Acts  as  a  iocai  constant  to  the  procedure 

procedure  DRAW_LINE  (FROM, 

TO  :  in  POINT); 

2.  out 

A  variable  which  may  only  be  assigned  a 
value  by  the  procedure 

procedure  HNO.MAX  (A,  B  :  in  Integer; 
MAX  :  out  Integer); 

3.  in  out 

A  variable  which  is  initialized  to  the  value 
of  the  actual  parameter  and  may  be 
assigned  a  value  by  the  procedure 

procedure  SORT  (DATA  :  in  out 
NAMES); 
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Default  Parameter  Values  (for  IN  only) 

type  DIRECTION  is  (ASCENDING, 
DESCENDING); 

procedure  SORT  (DATA  :  in  out  NAMES; 
ORDER  :  in  DiRECTION  :s  ASCENDiNG); 

SORT  (CLASS,  DESCENDiNG); 

SORT  (CLASS);  ~  uses  default  value 


procedure  SPACES  (COUNT  :  Integer  :=  1)  is 
begin 

for  i  in  1  ..COUNT  ioop 
Put  ("  "); 
end  ioop; 
end  SPACES; 


SPACES  (4); 

SPACES;  "  only  one  space  will  be  output 
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Parameter  Association 

Positional  notation 

Order  of  actual  parameters  must  match  order 
of  formal  parameters 

Named  notation 

Name  of  formal  parameter  is  associated  with 
actual  parameter 

procedure  SEARCH_FiLE  (KEY  :  in  NAME; 

iNDEX:  out  FiLEJNDEX); 


Positionai 

SEARCH.FILE  ("SMiTH  J”,  RECORD_ENTRY); 


Named  Notation 

3  variations  with  identical  resuits 

SEARCH_FILE  (KEY  s>  "SMITH  J", 

INDEX  s>  RECORD_ENTRY); 

SEARCH.FILE  (INDEX  =>  RECORD_ENTRY, 
KEY  =>  "SMITH  J"); 

SEARCH_FILE  ("SMITH  J", 

INDEX  =>  RECORD.ENTRY); 
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Return  Statement 


Used  to  terminate  a  procedure  or  function  and 
transfer  control  back  to  the  calling  routine 

In  a  function,  the  return  statement  indicates  the 
value  to  be  returned 

procedure  MIN  (A,  B  :  in  Integer; 

C  :  out  Integer)  is 

begin 

if  (A  <  B)  then 
C  :=  A; 
return; 
end  if; 

end  MiN; 

function  MIN  (A,  B  :  in  integer) 
return  Integer  is 

begin 

if  (A  <  B)  then 
return  A; 
end  if; 
return  B; 
end  MIN; 
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Procedure 


procedure  DIVIDE  (DIVIDEND, 

DIVISOR :  In  Integer; 
QUOTIENT, 

REMAINDER  :  out  Integer); 


procedure  DIVIDE  (DIVIDEND, 

DIVISOR  :  In  Integer; 
QUOTIENT, 

REMAINDER  :  out  Integer)  Is 

begin 

QUOTIENT  :s  DIVIDEND  /  DIVISOR; 
REMAINDER  :s  DIVIDEND  rem  DIVISOR; 
end  DIVIDE; 


DIVIDE  (120,  4,  A_QUOTIENT, 
A_REMAINDER); 


11 


L390H7 


Function 


function  AVERAGE  (A,  B,  C  :  in  Fioat) 

return  Fioat; 


function  AVERAGE  (A,  B,  C  :  in  Fioat) 

return  Fioat  is 

SUM  :  Fioat; 
begin 

SUM  :  A  +  B  +  C; 
return  SUM  /  3.0; 
end  AVERAGE; 


CURRENT_AVERAGE  :=  AVERAGE  (TEST1, 

TEST2,  TEST3); 


12 


L390H8 


Overloading 


The  same  name  or  operation  symbol  is  used  for 
different  entities  whose  scope  overlap  and  there  is 
no  ambiguity. 


Allowable  for: 

Operators 

Subprogram  identifiers 
Task  entry  identifiers 
Enumeration  literals 

Meaning  determined  by  operand,  parameters,  or 
context  of  use 
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Explicit  Resolution  with  Overioading 


2  means  of  explicit  resolution  in  meaning  for 
subprograms: 

1 .  Named  parameter  association 

2.  Quaiified  expression 


type  BEEF  is  (STANDARD,  GOOD,  CHOICE, 

PRIME); 

type  INTEREST  is  (PRIME,  BONDS, 

DISCOUNT); 

procedure  PROCESS  (THE_CUT  :  BEEF); 
procedure  PROCESS  (THE_RATE  :  INTEREST); 


PROCESS  (PRIME);  --  ambiguous  reference 
PROCESS  (THE.RATE  =>  PRIME); 
PROCESS  (BEEP(PRIME)); 
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Scope  and  Visibility  Rules 

3  types  of  visibility  possible  for  an  object: 

1 .  Directly  visible 

2.  Visible  by  selection 

3.  Hidden 

procedure  PI  is 
X  :  Integer; 

Y  :  Integer; 
procedure  P2  is 
X :  Integer; 
begin 

X  :s  4;  -•  X  of  P2  directly  visible 
P1.X  :=  3;  --  visible  by  selection 
Y  :=  5;  --  Y  of  P1  directly  visible 

end  P2; 

begin  --  PI 

P2;  --  directly  visible 
X  :=  6;  --  X  of  P1  directly  visible 

for  I  in  1..3  loop 
for  I  in  1..10  loop 

--  outer  I  is  hidden  in  inner  >  ^op 
end  loop; 
end  loop; 

end  PI ;  adapted  from  Benjamin 
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Programming  unit  that  allows  a  MHaction  of  ralaM  entities  to 
use  by  other  program  units 


package  STACKS  la 
type  STACK  is  privata; 
procadura  PUSH  (ELEMENT :  in  integer; 

ON  :  in  out  STACK); 
procedure  POP  (ELEMENT :  out  integer; 

ON  :  hi  out  STACK); 

private 

-STACK  defined 
end  STACKS; 


with  STACKS;  use  STACKS; 
procedure  MAiN  is 
A.STACK,  B.STACK :  STACK; 
begin 

PUSH  (10.  A  STACK); 

PUSH  (20.  B.STACK); 
end; 
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PrIvMt  and  Umlltd  PrIvMt  DMi  Typts 


Defined  in  a  package  specification 

Name  is  visible  to  user  but  implementation  detaiis  are  hidden 

Purpose:  to  restrict  operations  avaiiabie  outside  of  package  body 


17 


L390H13 


operations  availabto  on  private  data  types: 
Assignment  (:«) 

Relational  operators  (s.  /s) 
Subprograms  defined  in  its  package 


package  STACKS  Is 
type  STACK  Is  private; 
procedure  PUSH  (ELEMENT  :  In  Integer; 

ON:  In  out  STACK); 
procedure  POP  (ELEMENT  :  out  Integer; 

ON  :  In  out  STACK); 

private 

MAX  ELEMENTS  :  constant  Integer  :s  100; 
typellST  Is  array  (1..MAX_ELEMENTS)  of 
Integer; 
type  STACK  Is 
record 

STRUCTURE :  LIST; 

TOP  :  Integer  range  1..MAX.ELEMENTS; 
end  record; 
end  STACKS; 
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Umltsd  Prfvato  Dita  TVp« 


Operations  available  on  limited  private  data  types: 
Only  subprograms  defined  in  Its  package 


package  STACKS  la 
type  STACK  Is  Hmltad  private; 
procedure  PUSH  (ELEMENT :  In  Integer; 

ON:  In  out  STACK); 
procedure  POP  (ELEMENT  :  out  Integer; 

ON  :  In  out  STACK); 

private 

MAX  ELEMENTS  :  constant  integer  :s  100; 
typellST  is  array  (1..MAX_ELEMENTS)  of 
integer; 
type  STACK  is 
record 

STRUCTURE  :  LIST; 

TOP  :  integer  range  1..MAX.ELEMENTS; 
end  record; 
end  STACKS; 
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LECTURE  NUMBER:  040 


TQPICfSl  FOR  LECTURE: 
Ganarics  in  Ada 


\AL  QBJECTIVEfS^: 


1.  To  learn  the  features  of  Ada  generics. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

Often  we  find  components  of  a  system  that  are  very  similar  in  the  task  they  perform 
(e.g..  a  sort  procedure  for  an  integer  array,  a  sort  procedure  for  a  character  array, 
and  a  sort  procedure  for  a  real  array).  Separate  procedures,  each  of  which  uses 
the  same  sort  algorithm,  are  written.  A  means  of  creating  a  template  of  a 
component  (e.g.,  a  sort  template)  that  could  be  tailored  at  execution  time  would  be 
beneficial.  Ada  generics  provide  such  capability. 


(Learning  Label-  Today  we  are  going  to  ieam  ...) 

Today  we  are  going  to  examine  the  syntax  for  building  generic  program  units. 
GSMISmS.: 


1 .  Suppose  you  are  asked  to  write  a  procedure  to  return  the  successor 
of  a  given  element  in  a  "days  of  the  week”  list.  Suppose  a  further 
requirement  is  that  the  list  be  treated  as  a  circular  list  (e.g.,  the 
successor  of  the  last  element  is  the  first  element).  A  simple  solution 
is  shown  in  L4()OH1. 

L40OH2 

Three  more  generalized  solutions  are  shown  in  this  overhead.  Each 
of  these  attempts  at  gerrerality  has  drawbacks.  The  first  addresses  a 
logic  problem  by  taking  advantage  of  a  runtime  error;  the  seccmd  is 
not  completely  general  because  it  "hard  codes”  the  values  of  the  first 
and  last  elements  of  the  list;  the  third,  while  more  general,  has  limited 
potential  for  reuse  beyond  this  particular  instance  of  a  list. 


2.  L40OH3 

Ask  how  the  third  solution  on  L40OH2  could  be  modified  to  work  for 
a  list  of  integers  from  1  to  10.  Students  are  likely  to  quickly  realize 
that  defining  a  type  SIZE  as  shown  and  substibJting  SIZE  for  DAYS 
in  the  function  WRAP  will  work.  Similarly  ask  how  they  could  make 
this  function  work  for  the  letters  of  the  alphabet. 
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3.  a.  This  method  of  achieving  generality  by  changing  the  data  type 

upon  which  the  function  operates  is  the  way  generic 
subprograms  achieve  generality. 

L40OH4  shows  the  generic  for  the  WRAP  function.  Describe 
how  type  ELEMENT  can  be  instantiated  as  DAYS.  SIZE,  or  any 
other  discrete  data  type. 

b.  A  generic  program  unit  defines  a  template  from  which  other 
kinds  of  program  units  can  be  created,  as  in  L40OH4.  For 
example,  a  generic  subprogram  may  be  used  to  create  a  class 
of  similar  program  units  whose  only  differences  are  based  on 
the  types  upon  which  they  operate.  A  subprogram  or  package 
may  be  made  into  a  generic  in  Ada. 

4.  L40OH5 

a.  Discuss  the  three  aspects  to  defining  and  using  a  generic  unit: 
the  generic  unit  d^aration,  the  generic  subprogram  or 
package  body,  and  the  generic  instantiation  L40OH5.  The 
instantiation  is  the  process  of  creating  a  program  unit  from  a 
generic  program  unit.  A  generic  program  unit  cani  be  called 
directly,  but  an  instantiation  of  a  generic  program  unit  must  be 
created.  An  instantiation  is  a  declaration,  not  a  statement  and 
therefore  must  appear  in  the  declarative  part  of  a  program  unit 
which  uses  the  Unction. 

b.  L40OH6,  L40OH7,  L40OH8,  L40OH9.  L40OH10 

Use  these  overheads  to  illustrate  generic  subprograms, 
package  bodies,  and  instantiations. 

c.  One  possible  kind  of  parameter  to  a  generic  program  unit  is  a 
data  type.  Generic  formal  parameter  types  determine  the  type 
of  parameter  with  which  the  generic  can  be  instantiated  and  the 
operations  available  on  objects  of  that  type  within  the  generic 
body. 

L40OH11  shows  the  eight  generic  formal  parameter  types. 

d.  Another  possible  kind  of  parameter  to  a  generic  program  unit 
is  an  object  and  value.  Discuss  the  example  of  this  type  of 
parameter  as  shown  on  overhead  L40OH12. 

e.  The  last  kind  of  parameter  to  a  generic  program  unit  is  a 
subprogram.  A  generic  formal  subprogram  matches  with  any 
actual  subprogram  having  the  same  parameter  and  return-type 
profile.  Examples  are  given  on  overheads  L40OH13  and 
L40OH14. 
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PROCEttJRE. 

twchino  method  and  naadia: 
vooiMafY  intredu«Kl: 


IN8TRUGT10NAI.  MATERIALS: 
ovjfhaads: 


L40OH1 

L40OH2 

L40OH3 

L40OH4 

L40OH5 

L40OH6 

L40OH7 

L40OH8 

L40OH9 

L400H10 

L40OH11 

L40OH12 

L40OH13 

L40OH14 


Moving  towards  generic  units 
Moving  towards  ger)eric  units 
Moving  towards  generic  units 
Moving  towards  generic  units 
Ada  generic  unit 
Generic  subprograms 
Generic  subj3rograms 
Specification  of  generic  package 
Body  of  generic  package 
Instantiation  of  generic  package 
Generic  formal  parameter  types 
Generic  formal  objects 
Generic  formal  subprograms 
Generic  formal  subprograms  (cont.) 


handouts: 


RELATED  LEARNING  ACTIVITIES: 

(labs  and  exercises) 

Lab  029  -  Feedback  on  detailed  design  review  presentation 

READING  ASSIGNMENTS: 

Benjamin  Chapter  9  (pp.  79-87) 


RELATED  READINGS: 

Booch  Chapter  14  (pp.  243-257) 
Booch(2)  Chapter  12  (pp.242-257) 
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Moving  Towards  Generic  Units 


type  DAY  is  (MONDAY,  TUESDAY, 

WEDNESDAY,  THURSDAY, 
FRIDAY,  SATURDAY,  SUNDAY); 


function  WRAP  (D  :  DAYS)  return  DAYS  is 
begin 

if  D  =  SUNDAY  then 
return  MONDAY; 
elsif  D  =  MONDAY  then 
return  TUESDAY; 
elsif  D  =  TUESDAY  then 
return  WEDNESDAY; 
elsif  D  =  WEDNESDAY  then 
return  THURSDAY; 
elsif  D  =  THURSDAY  then 
return  FRIDAY; 
elsif  D  =  FRIDAY  then 
return  SATURDAY; 

gIsg 

return  SUNDAY; 
end  If; 
end  WRAP; 
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Moving  Towards  Generic  Units 


function  WRAP  (D  :  DAYS)  return  DAYS  Is 
begin 

return  DAYS'Succ  (D); 
exception 

when  Constralnt_error  => 
return  DAYS'Flrst; 
end  WRAP; 


function  WRAP  (D  :  DAYS)  return  DAYS  Is 
begin 

If  D  =  SUNDAY  then 
return  MONDAY; 
else 

return  DAYS'Succ  (D); 
end  WRAP; 


function  WRAP  (D  :  DAYS)  return  DAYS  Is 
begin 

If  D  =  DAYS'Last  then 
return  DAYS'Flrst; 
else 

return  DAYS'succ  (D); 
end  WRAP; 
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Moving  Towards  Generic  Unite 


function  WRAP  (D  :  DAYS)  return  DAYS  is 
begin 

if  D  =  DAYS'Last  then 
return  DAYS'First; 
eise 

return  DAYS'succ  (D); 
end  WRAP; 


What  modifications  wouid  you  make  to  WRAP  in 
order  to  provide  a  wrap-around  successor  capabiiity 
for  the  type  SiZE? 

type  SiZE  is  range  1..10; 
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Moving  Towards  Generic  Units 


"  generic  specification 

generic 

type  ELEMENT  is  (<>); 
function  WRAP_AROUND  (D  :  ELEMENT) 

return  ELEMENT; 


"  generic  body 

function  WRAP_AROUND  (D  :  ELEMENT) 

return  ELEMENT  is 

begin 

if  D  s  ELEMENTLsst  then 
return  ELEMENTFirst; 

OlS0 

return  ELEMENTSucc  (D); 
end  if; 

end  WRAP_AROUND; 


-  generic  instantiation 

function  WRAP  is  new 

WRAP.AROUND  (ELEMENT  s>  DAYS); 
function  WRAP  is  new 

WRAP_AROUND  (ELEMENT  s>  SiZE); 
function  WRAP  is  new 

WRAP_AROUND  (Character); 
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Ada  Generic  Unit 


Defines  a  template  from  which  other  kinds  of  program 
units  can  be  created 


Subprogram  or  package  can  be  a  generic 


Three  aspects  of  defining  and  using  a  generic  unit: 

1 .  Generic  unit  declaration 

2.  Generic  subprogram  or  package  body 

3.  Generic  instantiation 
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Generic  Subprograme 

A  subprogram  that  will  handle  values  of  arbitrary  type 

procedure  GENERIC.DEMO  is 
X,  Y  :  integer; 
generic 

-  generic  specification 
type  ELEM  is  private; 

procedure  EXCHANGE  (U,  V  :  in  out  ELEM); 

-  generic  body 

procedure  EXCHANGE  (U,  V  :  in  out  ELEM)  is 


T :  ELEM; 
begin 


end  EXCHANGE; 

-  end  of  generic  deciaration 

-  generic  instantiation 

~  (goes  in  program  that  invokes  SWAP) 
procedure  SWAP  is  new  EXCHANGE  (integer); 

-  generic  subprogram  caii 
begin 

X:=1; 

y  :*2; 

SWAP  (X,  Y); 
end  GENERiC.DEMO; 
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Generic  Subprograme 


generic 

-•  generic  specification 
type  ELEM  is  private; 
with  function  (LEFT,  RiGHT  :  ELEM) 
return  ELEM  is  o; 

function  SQUARiNG  (X  :  ELEM)  return  ELEM; 


Qonoric  body 

function  SQUARiNG  (X  :  ELEM)  return  ELEM  is 
begin 

return  X  *  X; 
end  SQUARiNG; 

-  end  of  generic  deciaration 


~  exampie  of  use 
with  SQUARiNG; 

~  instantiation  of  SQUARE 
procedure  FUNCnON.DEMO  is 
function  SQUARE  is  new  SQUARiNG  (Integer); 
X  :  Integer  :s  8; 
begin 

X  :=  SQUARE  (X); 
end  FUNCnON_DEMO; 
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Specification  of  Generic  Package,  QENERiC_LiST 


generic 

type  ELEM  ie  private; 

package  GENERiC.UST  is 
type  CELL  is  private; 
type  POiNTER  is  access  CELL; 
type  ARR  is  array  (integer  range  o)  of  ELEM; 
function  MAKE  (A  :  ARR)  return  POiNTER; 
function  FRONT  (P  :  POiNTER)  return  ELEM; 
function  REST  (P  :  POiNTER)  return  POiNTER; 
function  ADD_ON  (E  :  ELEM; 

P  :  POiNTER)  return  POiNTER; 


private 
type  CELL  is 
record 

VALUE  :  ELEM; 
LiNK  :  POiNTER; 
end  record; 
end  GENERiC.LiST; 
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Body  of  Generic  Package,  GENERIC_UST 

package  body  GENERIC_UST  is 

function  MAKE  (A  :  ARR)  return  POiNTER  is 
P  :  POiNTER; 
begin 

for  X  in  reverse  A'Range  ioop 
P  :s  ADD_ON  (A(X),  P); 
end  ioop; 
return  P; 
end  MAKE; 

function  FRONT  (P  :  POiNTER)  return  ELEM  is 
begin 

return  P.Vaiue; 
end  FRONT; 

function  REST  (P  :  POiNTER)  return  POiNTER  is 
begin 

return  P.LiNK; 
end  REST; 

function  ADD_ON  (E  :  ELEM; 

P  :  POiNTER)  return  POiNTER  is 

begin 

return  new  CELL'(E,P); 
end  ADD_ON; 

end  GENERtC_LtST; 
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Instantiation  of  Generic  Package,  GENERIC.UST 


type  PERSON  is 
rocord 

LAST.NAME  :  String  (1..10); 
SSN  :  SOC_SEC_NUM; 
BIRTHDAY  :  DATE; 
end  record; 

package  PERSON_LIST  Is 
new  GENERIC_UST  (PERSON); 


with  GENERIC_LIST; 

procedure  UST_DEMO  is 
package  INT_LIST  is 
new  GENERIC_UST  (ELEM  s>  Integer); 
P  :  INT_LIST.POINTER; 

begin 

P  INT_LIST.MAKE  ((1,  2,  3,  4)); 

P  :=  INT_LIST.ADD_ON  (5,  P); 
while  P  Is  null  loop 
Put  (INT_UST.FRONT  (P)); 

P  :s  INT.UST.REST  (P); 
end  loop; 
end  LIST.DEMO; 
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Generic  Formal  Parameter  Typee 


type  ITEM  le  private; 

-  Matches  almost  any  type 

--  Matches  any  type  for  which  assignment  and 
--  Tests  for  equality  are  avedlable 

type  LIMITED_ITEM  Is  limited  private; 

-  Matches  any  type  except  for  unconstrained 
--  Array  type 

type  DISCRETE_ITEM  is  (<>); 

--  Matches  any  discrete  type 

type  ARRAYJTEM  is  array  (DISCRETE_iTEM) 
OF  ITEM; 

type  PTRJTEM  is  access  ARRAY_ITEM; 
type  INTEGER_ITEM  Is  range  <>; 
type  FLOAT.ITEM  is  digits  <>; 
type  FIXED_ITEM  is  delta  <>; 
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Qeneric  Formal  Ol^octo 


gemric 

SIZE  :  Integer;  -  formal  object 
type  ELEM  le  private; 
package  STACK  is 
procedure  PUSH  (E  :  ELEM); 
procedure  POP  return  ELEM; 
end  STACK; 

package  body  STACK  is 
SPACE  :  array  (1..SIZE)  of  ELEM; 

INDEX  :  SPACE'range  1; 
procedure  PUSH  (E  :  ELEM)  Is 
begin 

SPACE  (INDEX)  :s  E; 

INDEX  :s  INDEX  •••  1; 
end  PUSH; 

procedure  POP  return  ELEM  is 
begin 

iNDEX  :s  iNDEX  - 1 ; 
return  SPACE  (INDEX); 
end; 

end  STACK; 

-  instantiation 

package  iNT_STACK  is  new  STACK  (25,  Integer); 
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Generic  Fomral  Subprograme 


generic 

type  ELEM  is  private; 
type  VECTOR  is  array  (integer  range  o) 
of  ELEM; 

with  function  ”>”  (X,  Y  :  ELEM)  return  Booiean; 
procedure  SORT  (A  :  in  out  VECTOR); 


with  SORT; 

procedure  GENERIC_DEMO  is 
type  iNT_VECTOR  is  array  (Integer  range  <>) 
of  Integer; 

A  :  INT_VECTOR  (1..10)  :s  (4,  7, 10,  2,  5,  8, 

1,  2,  6,  9); 

procedure  INT_SORT  is  new  SORT  (Integer, 

INT_VECTOR,  ”>"); 


--  instantiation 
begin 

INT_SORT  (A); 
for  X  In  A'range  loop 
Put  (X,  4); 
end  loop; 

end  GENERIC.DEMO; 
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Generic  Fomtal  Subprograms 


generic 

type  ELEM  is  private; 
type  VECTOR  is  array  (integer  range  o) 
of  ELEM; 

with  function  ">”  (X,  Y  :  ELEM) 
return  booiean  is  <>; 
procedure  SORT  (A  :  in  out  VECTOR); 


type  EMPLOYEE  is 
record 

NAME  :  String  (1  ..40); 
iD  :  integer; 
end  record; 

type  EMPLOYEE_ARRAY  is  array  (integer 
range  <>)  of  EMPLOYEE; 
function  GT  (A,  B  :  EMPLOYEE)  return  Boolean  is 
begin 

return  A.ID  >  B.ID; 
end  GT; 

-  instantiation 

procedure  EMPLOYEE_SORT  is  new  SORT 
(EMPLOYEE,  EMPLOYEE_ARRAY,  GT); 
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LECTURE  NUMBER:  041 

TOPIC(S)  FOR  LECTURE: 

Exceptions  and  exception  handlers  in  Ada 


INSTRUCTIONAL  QBJECTIVEfSI: 

1 .  To  learn  the  features  of  the  Ada  capabilities  regarding  exceptions  and 
exception  handlers. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

Ada  provides  a  mechanism  for  responding  to  and  managing  errors. 

(Learning  Label-  Today  we  are  going  to  learn ...) 

Today  we  are  going  to  learn  about  these  capabilities  and  how  to  use  them. 

CONTENTS: 

1 .  Ada  exceptions 

a.  Exceptions  are  error  conditions  that  may  arise  during  program 
execution  and  cause  the  suspension  of  nomiai  program  execution 
L410i1 .  Common  examples  include  division  zero  and  writing 
to  a  file  that  is  not  open.  Discuss  other  types  of  error  conditions. 
Real-time  systems  must  have  the  ability  to  handle  error  situations 
to  be  reliable;  termination  of  a  program  i4X)n  encountering  an  error 
is  not  always  desirable  and.  in  some  cases,  is  disastrous.  For 
example  a  pacemaker. 

b.  Raising  an  exc^on  brings  the  exception  or  error  situation  to 
attention  of  the  programmer  and  it  automatically  responds  by 
transferring  control  to  an  exception  handier.  Predefined  exceptions 
are  automatically  raised  by  Ada;  user-defined  exceptions  are 
raised  by  the  ritee  statement  L410H2.  The  scqse  of  user- 
defined  exceptions  Is  the  same  as  identifiers. 


2.  Ada  exception  handlers 

a.  An  exception  handler  is  that  portion  of  code  which  responds  to  an 
exception  L410H3.  An  exception  handler  allows  a  program  to 
recover  from  an  error  or.  at  a  minimum,  print  a  meaningful  error 
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message  and  terminate  the  program  gracefully. 

b.  Exception  handlers  begin  with  the  word  exception  and  may  appear 
at  the  end  of  a  bogfn..end  block  or  frame.  This  means  that  an 
exception  handler  can 

appear  at  the  end  of  the  body  of  a  subprogram,  package,  task  and 
generic  unK. 

3.  Exception  propagation 

a.  If  no  exception  handier  is  included  in  a  unit,  raising  the  exception 
causes  several  things  to  happen.  Rrst,  execution  of  the  unit  is 
terminated  and  the  exception  Is  "propagated"  to  a  unit  at  the  next 
highest  level  that  does  contain  an  appropriate  handler  L410H4. 
How  the  exception  is  propagated  depends  on  the  type  of  frame  in 
which  it  was  raised. 

Discuss  each  of  the  results  of  an  exception  being  raised  in  each 
of  the  program  units  in  which  an  exception  can  be  defined.  For 
the  frames  in  L410H4,  each  frame  terminates  and  then:  for  a 
block  an  exception  is  re-raised  at  the  point  immediately  after  the 
block,  for  a  subprogram  the  same  exception  is  raised  at  the  point 
immediately  following  the  subprogram  cail;for  a  package  which  is 
a  library  unit  the  main  program  dies  otherwise  the  exception  is 
raised  in  the  next  highest  level;  and  a  task  merely  terminates 
without  re-raising  the  exception.  Discuss  the  example  in  L41  OHS 

b.  Special  form  of  raise  statement  can  be  used  inside  an  exception 
handler  to  re-raise  the  exception  currently  being  handled  to 
propagate  the  exception  to  the  next  higher  level.  See  example  of 
RAISE  used  to  propagate  an  exception.  L410H6 

c.  Discuss  User  defined  exceptions  L410H7.  Trace  the  example  in 
L410H8 


PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 
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INSTBUCTIQNAL  MATERIALS: 


overheads: 

L410H1 

Ada  exceptions 

L410H2 

Predefined  exceptions 

L410H3 

Exception  handlers 

L410H4 

Exception  propagation 

L410H5 

Exaniple  of  exception  propi^jation 

L410H6 

Special  use  of  Raise  statement 

L410H7 

User-defined  exceptions 

L410H8 

Example  of  user-defined  exception 

handouts: 

(labs  and  exerdses) 

Lab  030- 

Video  on  Code  inspections 

BEADING  ASSIGNMENTS; 

Benjamin  Chapter  1 2  (pp.  1 1 1  >1 1 7) 


RELATED  READINGS: 

Booch  Chapter  17  (pp.  312*322) 
Booch(2)  Chapter  15  (pp.31 8-335) 
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Ada  Exceptions 


Exception 

An  error  condition  which  may  arise  during 
program  execution  and  cause  suspension  of 
normai  program  execution 

Exception  handier 

A  portion  of  program  text  specifying  a  response 
to  an  exception 

Aliows  program  to  recover  from  an  error  or,  at  a 
minimum,  print  a  meaningfui  error  message  and 
terminate  the  program  gracefuiiy 

Raising  an  exception 

Brings  the  exception  condition  to  the 
programmer's  attention 

Causes  transfer  of  control  to  an  exception 
handler 

raise  STACK-OVERFLOW; 
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Predefined  Exceptions 


Predefined  by  the  language  s|.  cation 


Automatically  reported  or  reused  in  Ada  programs 


Examples: 

Numeric_error  Attempt  to  divide  by  zero  or 

occurrence  of  numeric  overflow  on 
a  numeric  operation  such  as 
addition 

Constraintjsrror  Attempt  to  violate  some  form  of 

constraint,  including  range 
constraints,  index  constraints, 
or  discriminant  constraints 

Storagejerror  Insufficient  storage  available  to 

satisfy  the  run-time 
requirements  of  a  program 
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Exception  Handlers 


Specifies  the  exception  to  be  bandied  and  the  action 
to  be  taken  for  each  exception 

Oniy  appear  at  the  end  of  four  different  program 
units: 

A  begin..end  biock 

Body  of  a  subprogram 

Body  of  a  package  or  generic  unit 

Body  of  a  task 


with  TextJO;  use  Text_IO; 
procedure  EXCEPnON_DEMO  is 
X :  Integer  range  1..20; 
begin 
X:s43; 

-  other  statements 

exception 

when  Constraintjerror  => 

Put  ("Constraint  Error  Exception  "); 
when  others  -> 

Put  ("Other  Exception  "); 
end  EXCEPTION.DEMO; 
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Exception  Propagation 


When  an  exception  is  raised  in  a  unit  that  does  not 
define  an  exception  handler  for  that  exception, 
execution  of  the  unit  is  terminated  and  the  exception 
is  propagated  to  a  unit  that  does  contain  the 
appropriate  handler 


How  exception  is  propagated  depends  on  where  it 
was  raised 

A  begin..end  block 

Body  of  a  subprogram 

Body  of  a  package 

Body  of  a  task 
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Example  of  Exception  Propagation 

with  Text_IO;  use  TexUO; 

procedure  EXCEPT_DEMO  is 
procedure  RAiSE_EXC  is 
begin 

Put(”  raise_exc"); 
raise  ConstrainLerror; 
end  RAiSE_EXC; 

procedure  HANDLE_EXC  is 
begin 

Put(”  handie_exc"); 

RAiSE_EXC; 

exception 

when  Constraintjerror  => 

Put  ("  Constraint  error  caught"); 
end  HANDLE_EXC; 

begin 

Put  ("ExcepLdemo:  caiiing  handiejexc"); 
HANDLE_EXC; 

Put  ("Except_demo:  back  from  handiejexc”); 
exception 

when  ConstrainLerror  » 

Put  ("Constraint  error  in  ExcepLdemo"); 

end  EXCEPT_DEMO; 

8  L410HS 


Special  Use  of  Raise  Statement 


Special  form  of  raise  statement  can  be  used  inside 
an  exception  handler  to  re-raise  the  exception 
currently  being  handled 


begin 

"  allocate  some  resource  which  shouldn't 
"  be  permanently  allocated;  causes  exception 

exception 
when  others  » 

-  code  might  clean  up  resources  that  were 
~  allocated  in  the  enclosing  unit 

raise; 

end; 
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User-defined  Exceptions 


Programmers  may  define  their  own  exceptions 


Exampies  of  exception  declarations: 

TABLE_FULL  :  exception; 
iLLEGAL_DATA  :  exception; 
STACK_OVERFLOW :  exception; 


Scope  of  exception  name  is  same  as  scope  of  other 
identifiers  in  a  declaration 
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Example  of  User*defined  Exception 
with  TextJO;  use  Text_IO; 
procedure  SCOPE_DEMO  is 
E :  exception; 

procedure  P  is 
begin 
raise  E; 
end  P; 

procedure  Q  is 
E :  exception; 
begin 
P; 

exception 
when  E  » 

PuUine  ("Handier  for  Q.E"); 
end  Q; 

begin 

Q;  ~  raise  exception  handler  in  Q 
P;  -  raise  exception  handler  below 

exception 
when  E -> 

PuUine  ("Handler  for  Scope_Demo.E"); 
end  SCOPE.DEMO; 
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LECTURE  NUMBER:  042 

TQPIC(S)  FOR  LECTURE: 

Sequential  and  direct  files  in  Ada 


INSTRUCTIONAL  QBJECTIVEfSt: 

1 .  To  learn  the  Ada  features  regarding  sec^ential  and  direct  files. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

When  we  first  began  looking  at  the  syntax  of  Ada,  we  examined  the 
capabilities  for  files  as  provided  in  Text.K).  TextJO  works  on  text  files 
which  are  treated  as  a  stream  of  characters  including  end  of  line  terminators, 
end  of  page  terminators,  and  end  of  file  terminator. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we  are  examining  how  Ada  supports  sequential  and  direct  files. 


CONTENTS: 

1 .  Ada  files 

a.  L420H1 

Ada  provides  three  packages  for  file  services  TextJO  which 
supports  text  files,  SoquentialJO  which  supports  sequential 
files,  and  Direct  JO  which  supports  direct  access  files. 

b.  Sequentiai JO  and  Direct  JO  are  generic  packages  and,  unlike 
TEXTJO,  must  be  instantiated.  They  provide  the  same  data 
type  (File.Type)  as  TextJO  and  the  same  file  modes. 
Direct  JO  also  provides  another  file  mode  lnout_file  which 
allows  for  a  read-write  file.  Both  files  provide  the  same 
procedures  as  TextJO  for  creating,  deleting,  opening,  closing, 
and  resetting  files. 

c.  L420H2 

Sequential  JO  creates  a  sequential  binary  file  of  the  same 
data  type.  Three  additional  subprograms  are  provided  by  this 
package  for  the  support  of  sequential  files:  Read,  Write,  and 
End_of_file. 

d.  L420H3 
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In  DiractJO,  files  are  viewed  as  a  set  of  elements  occupying 
consecutive  positions.  An  element  in  the  file  can  be  randomly 
accessed  and  updated  by  its  index  which  indicates  its  position 
in  the  file.  The  index  numbering  for  a  file  starts  at  1 .  An  open 
direct  access  file  maintains  a  current  index  which  is  the  index 
of  the  component  used  in  the  next  read  or  write  operation.  The 
following  additional  subprograms  are  provided  in  OirectJO: 
Read,  Write,  Setjndex,  Index,  Size,  and  End_of_Flle 

e.  L420H4 

The  subprograms  for  reading  and  writing  can  work  off  the 
current  index  or  an  index  can  be  specified  in  the  parameter  list. 
If  an  index  is  specified  it  becomes  the  current  index.  For  both 
operations,  the  current  index  is  incremented  by  one  after  the 
operation  is  done. 

f.  L420H5 

Discuss  the  example  of  sequential  I/O  shown. 


PROCEDURE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  this  lecture. 


vocabulary  introduced: 


INSTRUCTIONAL  MATERIALS: 


gverhsads: 

L420H1 

L420H2 

L420H3 

L420H4 

L420H5 

iiaodfiuls: 


Ada  files 
Sequential  files 
Direct-access  files 
Direct-access  files  (cont.) 

Example  of  usefulness  of  SequentiaIJO 


RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 

READING  ASSIGNMENTS: 

Benjamin  Chapter  10  (pp.  89-96) 

RELATED  READINGS: 

Booch  Chapter  19  (pp.  356-373) 
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AdaniM 


Ada  provides  three  packages  for  file  services: 

TextJO  A  package  providing  support  for 

text  files 

SequentiaMO  A  generic  package  providing 

support  for  sequential  files 

DirectJO  A  generic  package  providing 

support  for  direct-access  files 

Uses  another  file  mode 

lnout_File 
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Sequential  Files 


Subprograms  provided  in  SequentiaMO: 

procedure  Read  (RIe  :  in  File_Type; 

Item  :  out  Element_Type); 


procedure  Write  (File  :  in  File_Type; 

Item :  in  Element_Type); 


function  End_of_File  (File  :  in  Flle_Type) 
return  Boolean; 
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Direct-Access  Files 


File  is  viewed  as  a  set  of  elements  occupying 
consecutive  positions;  an  element  at  arbitrary 
position  can  be  randomly  accessed  and  updated 
by  its  index 

Numbering  of  index  starts  at  1 


Subprograms  provided  in  DirectJO: 

procedure  Read  (File  :  in  File_Type; 

Item  :  out  Element_Type); 

procedure  Read  (File  :  in  File_Type; 

Item  :  out  Element_Type; 
From  :  in  Positive_Count); 

procedure  Write  (File  :  in  File_Type; 

Item  :  in  ElementJType); 

procedure  Write  (File  :  in  File.Type; 

Item :  in  ElementJType; 
To  :  in  Positive_Count); 
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Direct-Access  Hies  (cent.) 


More  subprograms  provided  in  DireetJO: 


procedure  Setjndex  (File  :  in  File_Type; 

To  :  in  Positive_Count); 


function  Index  (File  :  in  FileJType) 

return  Positive_count; 


function  Size  (File  :  in  Hle_Type) 

return  Count; 


function  End_of_File  (File  :  in  FileJType) 

return  Boolean; 
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Example  of  Usefulness  of  SequentlaIJO 


generic 

type  ITEM  Is  private; 
with  function  (LEFT,  RIGHT  :  ITEM) 
return  Boolean  Is  <>; 
procedure  GENERIC_MERGE_SORT 
(INPUT_FILE_NAME, 
OUTPUT_FILE_NAME  :  In  String); 


with  SequentlaIJO; 
procedure  GENERIC.MERGE.SORT 
(INPUT.FILE  NAME, 
OUTPUT_FILE_NAME  :  In  String)  is 

package  ITEMJO  is  new  SequentlaIJO 
(ITEM); 
use  ITEMJO; 

--  rest  of  program 

end  GENERIC_MERGE_SORT; 


7 


L420HS 


LECTUBB  NUtgER:  043 


TOPmFQRLECTUflE: 

tMktin  Adi 


IMSTRUCTfQNAL  QBJECTIVEfS^: 

1.  To  team  the  features  of  Ada  tasks. 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

L430H1  We  have  discussed  several  Ada  program  units.  Tasks  are  another 
type  of  Ada  program  unit.  They  provide  paraHei  processing.  We  will  find  that 
although  they  resemble  packers,  there  are  several  significant  differences 
between  tasks  and  pack^es. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 


gQNTENIS: 

1.  Ada  tasks 

L430H2 

a.  Tasks  are  the  programming  unit  in  Ada  which  provides  parallel 
processing;  In  other  words,  a  task  can  be  activated  and 
executed  concurrently  with  other  program  units.  A  task  is  not 
itself  a  compilation  unit  but  must  be  declared  within  a 
subprogram,  package,  or  generic  package.  A  task  has  a 
specification  atnd  a  body.  A  task  is  declared  in  the  declarative 
part  of  these  programming  units.  A  task  is  activated  when  the 
begin  statement  of  its  parent  unit  is  reached.  A  task  may  be 
called  by  any  other  programming  unit. 

b.  A  task  can  perform  functions  such  as  mutual  exclusion  and 
synchronization,  which  had  been  limited  to  operating  systems. 

L430H3 

c.  The  entry  declaration  in  the  task  specification  defines  the 
functions  or  services  that  the  task  provides.  The  entry 
declaration  is  similar  to  a  subprogram  dedaration. 

L430H4 

d.  The  task  body  contains  the  accept  statement  which 
corresponds  to  the  entry  in  the  specification. 
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L430H5 

0.  A  rendezvous  is  the  meeting  of  the  caing  unit  and  caned  task. 
This  is  an  indivisible  action  where  the  calling  unit  and  called 
task  are  locked  together. 

L430H6 

f.  The  stages  of  the  calling  unit  and  called  task  are  shown  on 
overheads  L430H7. 

g.  Use  the  program  in  lecture  16  to  reinforce  what  students  have 
learned  about  Ada. 


PROCEDURE: 

teaching  method  and  media: 

Lecture  and  overheads  are  the  chief  media  for  this  lecture. 


vocabulary  introduced: 


INSTRUCTIONAL 

MATERIALS: 

overheads: 

L430H1 

Ada  program  units 

L430H2 

Ada  tasks 

L430H3 

Task  specification 

L430H4 

Task  body 

L430H5 

Rendezvous 

L430H6 

Stages  of  a  rendezvous  (entry  call  first) 

L430H7 

Stages  of  a  rendezvous  (accept  first) 

handouts: 

RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 


READING  ASSIGNMENTS: 

Benjamin  Chapter  11  (pp.  97-109} 


BgLATED  RgADJtiQS: 

Booch  Chapter  16  (pp.  276-309) 
Booch(2)  Chapter  14  (pp.280-315) 
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Ada  Program  Unita 


Procedures  and  functions 


Packages 


Tasks 
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Ada  Tasks 


Ada  program  unit  that  can  be  activated  and 
executed  concurrentiy  with  other  program  units 


Ailows  certain  capabiiities  previousiy  performed 
only  by  operating  system  to  be  performed  in 
language 


Not  a  compilation  unit;  declared  within  a 
subprogram,  package,  or  generic  package 


Has  specification  and  body 


Aspects  involved  in  a  task: 
Task  entry 
Entry  call 
Accept  statement 
Rendezvous 
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Task  Specification 

Defines  interface  which  other  (related)  program 
components  use  to  interact  with  the  task 

Interface  consists  of  task  entry  declarations 
Like  the  subprogram  declarations  in  a 
package  specification 

Define  functions  or  services  that  the  task 
provides 


task  SINGLE.TELLER  is 
entry  DEPOSIT  (ID  :  CUSTJD; 
VAL  :  MONEY; 

STAT :  out  STATUS); 
entry  WITHDRAW  (ID  :  CUSTJD; 

VAL  -.MONEY; 

STAT  :  out  STATUS); 
entry  BALANCE  (ID  :  CUSTJD; 
VAL  :  out  MONEY; 
STAT :  out  STATUS); 
end  SINGLE.TELLER; 


--  entry  call  to  above  task 

SINGLE_TELLER.DEPOSIT  (ID,  AMOUNT, 
STAT); 
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Task  Body 


task  SINGLE_TELLER  is 
function  RANDOM_TRANSACTiON_TiME  is 
begin 
ioop 

ooloct 

accept  DEPOSiT  (iD  :  CUSTJD; 

VAL  :  MONEY; 

STAT  :  out  STATUS)  do 
BANK_DATABASE.VERIFY_CUSTJD 
(iD,  VALiD); 

N  not  VALiD  then 
STAT  :=  BAD_CUSTJD; 

OlSG 

BANK_DATABASE.DEPOSiT  (iD,  VAL); 
STAT  :=  SUCCESS; 
end  H; 

end  DEPOSiT; 
or 

accept  WiTHDRAW  (...)  do..end; 
or 

accept  BALANCE  (...)  do..end; 
end  seiect; 
end  ioop; 

end  SiNGLE_TELLER; 
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Rendezvous 


Meeting  of  calling  and  called  tasks 


Indivisible  action 


Two  tasks  locked  together;  calling  task  waits  while 
called  task  executes;  after  called  task  completes, 
both  tasks  proceed  independently  of  each  other 


Achieves: 

Synchronization 
Exchange  of  information 
Mutual  exclusion 
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stage  of  a  Rendezvoua 
Accept  Hret 


Introduction  to  use  cases 


INSTRUCTIONAL  OBJECTIVEfSI: 

1.  Understand  Jacobson's  concept  of  use  cases  and  their  use  as  an 
analysis,  design,  and  test  tool. 

2.  Be  able  to  develop  use  cases. 

SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

We  have  discussed  a  number  of  ways  to  elidt  requirements  from  the 
customer  and  user.  The  ability  for  a  sofbvare  developer  to  consider  multiple 
viewpoints  of  the  system  and  to  consider  a  system  from  an  external  (to  the 
system)  is  crucial.  The  requirements  for  a  system  describe  the  desired 
external  behaviors  of  the  system.  A  methodology  has  been  developed 
recently  which  emphasizes  the  external  behavior  of  a  system  as  it  relates  to 
the  system  users. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we're  going  to  describe  this  method.  It  was  developed  by  Jacobson 
and  is  called  the  use  case  driven  approach. 

CONTEMTS: 


1 .  Introduce  Jacobson's  use  case  concept.  Use  cases  are  one  part  of 
Jacobson's  requirements  model.  The  other  components  are  a 
problem  domain  object  model  and  a  user  interface  model. 

Use  cases  are  developed  early  so  that  the  requirements,  user 
interface,  and  test  teams  can  get  another  view  of  the  system. 

2.  L460H1 

a.  Jacobson's  imia  modal  involves  gdOES  and  as 

tools  to  identify/define  what  exists  outside  the  system  (actors) 
and  what  should  be  performed  by  the  system  (use  cases).  The 
actors  include  the  users  and  user  roles.  Consider  the  Koff 
system.  Who  are  the  actors? 

(1)  Customer  (2)  Operator  (3)  Owner 

Contrast  how  these  actors  interact  with  the  system.  Among 
other  things,  the  customer  removes  tapes  and  returns  tapes; 
the 
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operator  maintains  the  machine  and  stocks  tapes;  the  owner 
gets  reports  and  determines  rental  and  sale  tapes. 

b.  Use  cases  represent  what  the  users  should  be  able  to  do  with 
the  system.  Each  use  case  is  a  complete  course  of  events 
initiated  by  an  actor  and  it  specifies  the  interaction  that  takes 
place  between  the  actor  and  the  system.  Each  time  a  user 
uses  the  system,  he/she  will  perform  a  behaviorally  related 
sequence  of  transactions  in  a  dialogue  with  the  system.  Each 
of  these  is  a  use  case,  or  a  scenarios.  A  detailed  description 
is  written  for  each  use  case. 


3.  a.  L460H2 

Jacobson  discusses  a  recycling  system  as  a  first  example.  The 
system  consists  of  a  machine  that  accepts  a  variety  of 
recyclable  materials  deposited  by  a  users.  Once  a  user 
deposits  items,  the  machine  generates  a  receipt  based  on  the 
items  deposited. 

b.  L460H3 

The  customer  should  be  able  to  deposit  items.  This  forms  one 
use  case.  Deposit  item.  Discuss  it. 

c.  L460H3 

The  operator  should  be  able  to  get  a  daily  report  of  what  items 
have  been  deposited.  This  is  another  use  case,  Generate 
Daily  Report.  Discuss  it. 

4.  L460H4 

As  requirements  analysis  continues  and  more  information  is 
determined,  the  use  cases  will  be  described  in  more  detail.  Discuss 
this  elaboration  of  the  Deposit  Item  use  case. 


5.  Introduce  the  concept  of  "extends”  with  use  cases.  One  use  case  can 
be  inserted  into  another,  thus  extending  the  other  use  case.  This  is 
particularly  useful  in  considering  abnormal  conditions. 

L460H5 

Discuss  Item  Is  Stuck  as  an  example  of  this.  Note  that  Deposit  Item 
is  described  completely  independent  of  this  new  use  case. 


6.  Work  through  a  use  case,  called  Withdraw  Tape,  for  a  customer 
withdrawal  of  a  rental  tape  in  the  Koff  system.  Sm  if  anyone  notices 
that  a  receipt  is  never  issued  to  the  customer.  Discuss  this  oversight. 
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7.  Pick  any  of  the  use  case  examples  and  dtecuee  test  cases  that  could 
be  developed  for  it  Point  out  that  the  use  case  approach  has 
application  in  both  structured  analysis  and  ofagfect-orfenied  analysis. 


PRQCEPyBE: 

ttwifihing  mfttfwri  and  (Twwfi§: 


vocabulary  introduced: 
use  case 
scenario 
actor 


INSTRUCTIQNAI,  MATERIALS: 


•n-iiii- 


RELATED  LEARRINfi  AgUVIHES: 

(labs  and  exercises) 

Lab  032  Code  Inspections 

READING  ASSISNMENTS: 

RELATED- READINGS: 

Jacobson  Chapter  7  (pp.  148*195) 
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Jacobson's  Use  Case  Model 


Uses  actors  and  use  cases  as  tools  to  identify: 

what  exists  outside  the  system  (actors);  and 

what  should  be  performed  by  the  system  (use 
cases). 


Each  time  a  user  uses  the  system,  he/she  will 
perform  a  behaviorally  related  sequence  of 
transactions  in  a  dialogue  with  the  system.  Each 
of  these  is  a  use  case,  or  a  scenarios.  A  detailed 
description  is  written  for  each  use  case. 
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Deposit  Item  Use  Case 


Deposit  Item  is  started  by  Customer  when  he/she 
wants  to  return  cans,  plastic  containers,  or  glass 
containers.  With  each  item  that  Customer  places 
in  the  recycling  machine,  the  system  will  increase 
the  received  number  of  items  from  Customer  as 
well  as  the  daily  total  of  this  particular  type.  When 
Customer  has  turned  in  all  the  items,  he/she  will 
press  the  receipt  button  to  get  a  receipt  containing 
a  summary  of  the  deposited  items  and  the  amount 
due. 
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Generate  Daily  Report  Use  Case 


Generate  Daily  Report  is  started  by  Operator 
when  he/she  wants  to  print  out  information  about 
the  items  deposited  that  day.  The  system  will 
print  out  how  many  of  each  deposit  items  have 
been  received  this  day,  as  well  as  the  overall  total 
for  the  day.  The  total  number  will  be  reset  to  zero 
to  start  a  new  daily  report. 
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More  Detailed  Depoait  Item  Uee  Caee 

The  course  of  events  starts  when  the  customer  presses 
the  ”start-button"  on  the  customer  panel. 

The  customer  can  now  deposit  items  via  the  customer 
panel.  The  sensors  inform  the  system  that  an  object 
has  been  inserted.  They  also  determine  the  size  and 
type  of  the  deposit  item  and  return  these  results  to  the 
system. 

The  daily  total  for  the  deposited  item  is  incremented,  as 
is  the  number  of  deposited  items  of  that  type  from  this 
customer. 

When  the  customer  is  finished  depositing  items,  he/she 
asks  for  a  receipt  by  pressing  the  "receipt  button”  on  the 
customer  panel. 

The  system  compiles  the  information  to  be  printed  on 
the  receipt.  For  each  type  of  deposit  item,  its  return 
value  and  the  number  of  deposited  items  from  this 
customer  is  extracted. 

The  information  is  printed,  with  a  new  line  for  each 
deposit  item,  by  the  receipt  printer. 

Finally,  the  grand  total  for  all  returned  deposit  items  is 
extracted  by  the  system  and  printed  out  by  the  receipt 
printer. 


7 


L460H4 


Extending  a  Use  Case 


Item  Is  Stuck  Use  Case 

Item  Is  Stuck  is  inserted  into  Deposit  Item 
when  Customer  deposits  an  item  that  gets 
stuck  in  the  recycling  machine.  Operator  is 
called  and  Customer  cannot  turn  in  more 
items  until  Operator  informs  him/her  that  the 
machine  c&..i  be  used  again. 
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Implementation  languages 

INSTRUCTIONAL  QBJEgTtVaS): 

1 .  Understand  the  factors  Involved  in  selecting  a  programming  language. 

2.  Understand  factors  that  affect  the  quality  of  source  code. 

SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 

All  of  you  have  experience  in  several  programming  languages  (Pascal  from 
CS-1  and  CS-2,  assembly  language,  and  Ada  in  this  class).  Some  of  you 
also  know  other  languages  (COBOL,  C,  FORTRAN). 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

Today  we're  not  going  to  look  at  any  language  in  particular,  but  rather  look 
at  some  factors  that  should  be  considered  in  evaluating  languages.  As  we 
do  this,  think  of  the  languages  that  you  know  and  consider  how  aspects  of 
the  language  are  supportive  of  software  engineering  principles  and  how  other 
aspects  are  not.  You  may  have  thought  of  a  language  strictly  as  an 
implementation  tool.  This  was  likely  the  case  in  CS-1 . 

At  this  point,  however,  you  should  be  able  to  look  beyond  that.  For  example, 
Mynatt's  detailed  design  checklist  includes  "Is  the  design  appropriate  for  the 
target  programming  language?"  Similarly,  in  our  discussions  of  your  project, 
the  question  of  language  support,  i.e.  how  easily  a  design  is  impiementable, 
has  come  up. 


CONTENTS: 

NOTE:  This  lecture  is  based  on  Mynatt's  discussion  of  choosing  a 

programming  language  in  section  5.7.  She  offers  many  good 
examples  and  observations  to  support  the  ideas  outlined  here. 

1.  Ask  students  about  the  impact  of  language  choice,  is  the  choice  of 
language  important?  Why? 

Make  sure  student  responses  include  significant  impact  the  language 
will  have  on  such  things  as: 

i  Maintainability, 

ii  Coding  and  testing, 

iii  The  amount  of  distortion  between  the  implementation  model 

and  the  design  model. 
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iv  the  effectiveness  of  the  personnel. 

L470H1 

Note  that  good  code  can  be  written  in  any  language,  even  assembly 
language,  but  it  is  much  easier  if  the  language  itself  actively  supports 
the  production  of  efficient,  reliable,  maintainable  software.  Point  out 
that  there  are  trade-offs  involved  and  that  no  single  language  can 
simultaneously  achieve  a  high  degree  of  success  in  each  of  these 
areas.  For  example,  Ada  is  highly  maintainable  but  has  low 
performance  in  terms  of  execution  speed  until  properly  tuned.  On  the 
other  hand,  C  is  difficult  to  maintain  but  has  a  high  level  of 
performance  in  terms  of  execution  speed. 

Ask  what  is  the  "language  of  choice"  currently?  In  terms  of  the 
number  of  lines  of  code  in  existence  and  still  being  maintained,  the 
answer  is  COBOL;  the  vast  majority  of  software  world-wide  is  written 
in  COBOL. 

L470H2  -  Pragmatic  factors  in  choosing  a  language. 

Point  out  that  the  question  of  what  language  is  going  to  be  used  to 
implement  a  project  does  not  even  arise  in  many  cases.  Why? 
Because  more  often  than  not  the  choice  is  dictated  by  the  by  the 
customer  or  the  organization  or  some  standard,  or  something  else 
beyond!  tiie  particular  project.  What  are  some  of  these  pragmatic 
factors? 

a.  Dictated  by  client.  The  client  wants  it  written  in  BASIC,  or 
COBOL,  or  Ada,  for  example.  There  are  many  reasons  for 
such  a  requirement  by  the  client,  including  organizational  or 
sponsor  standards  that  call  for  a  particular  language  (e.g.  DoD 
and  Ada),  availability  of  compiler  (and/or  other  software 
development  tools). 

b.  Existing  expertise.  Selecting  a  new  language  over  one  in 
which  the  coders  are  experienced  involves  training.  The 
training  needs  to  be  sufficient  to  take  advantage  of  the  features 
of  the  new  language  in  order  to  have  the  language  used 
effectively. 

Concerning  the  question  of  which  language  is  "most  suitable" 
for  a  given  project,  work  through  Schach's  example  involving 
the  QQQ  corporation  (pages  340-341 ). 

c.  Language  used  in  other  projects,  both  previous  and  concurrent. 
Cite  DoD  problems  that  led  to  development  of  Ada. 

d.  Concurrency 
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3.  L470H3 

Language  characteristics  that  can  support  efficient,  reliabie. 

maintainable  software.  First  ask  class  to  list  some  characteristics. 

a.  Modularity  -  A  languc^e  should  support  the  partitioning  of  a 
large  product  into  modules.  To  do  so  it  must  support  separate 
compilation  of  modules. 

Note  Ada's  compilafion  units  (procedures,  functions,  packages, 
generics,  and  tasks),  each  of  wNch  consists  of  two  parts  (the 
specification  and  the  body)  which  are  themselves  separately 
compiled. 

b.  Power  and  surtabiRty  -  Power  refers  to  a  language’s  ability  to 
carry  out  programming  tasks  simply  an  with  little  ’  'jramming 
effort.  Power  also  is  relative  to  the  type  of  prouiem  being 
solved.  Different  languages  are  suitable  for  different  purposes. 

c.  Simplicity,  clarity,  orthogonality 

i  Simplicity  refers  to  the  size  of  its  vocabulary.  Some 
languages  are  so  large  that  it  is  difficult  to  become 
familiar  with  the  entire  language.  This  can  result  in  a 
tendency  for  subsets  to  be  adopted  which,  in  turn,  leads 
to  incompatible  subsets.  Discuss  Pascal  as  simple,  PL/I 
and  Ada  as  complex. 

il  Clarity  refers  to  how  natural,  meaningful,  and 
unambiguous  the  language  is  to  the  programmer.  Some 
languages  are  more  machine/architecture  oriented  and 
thus  less  problem  oriented  (and  less  clear), 
iii  Orthogonality  of  a  language  refers  to  its  consistency  in 
allowing  language  features  to  be  combined.  It  relates  to 
clarity  and  simplicity  because  lack  of  orthogonality 
results  in  lots  of  special  cases  for  the  programmer  to 
remember.  Examples  include  Pascal's  restrictions  on 
reading/writing  certain  types. 

d.  Syntax  -  It  is  desirable  that  the  syntax  be  simple,  consistent, 
and  supportive  of  dear  code.  Examples  include: 

i  method  of  indicating  blocks  (begin-end,  etc).  Note  the 
expridt  keyword  approach  of  some  languages  (if*endif) 
versus  the  begin-end  approach  of  others. 

ii  format  of  statements  -  can  encourage  or  discourage  use 
of  white  spece,  indentation. 

iii  mles  for  identifier  names  -  can  encourage  or  discourage 
use  of  meaningful  identifiers. 
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Structured  programmirig  artd  control  structures  -  An  accepted 
definition  of  structured  programming  includes: 

i  selection  and  iteration  control  structures  with  controlled 
goto  (forward  direction  only,  heavily  restricted,  perhaps 
to  exception  handling); 

ii  one  entry,  one  exit 

A  ianguage  should  have  a  strong  effective  implementalion  of 
the  basic  control  structures. 

Exception  handling  -  Most  programming  languages  do  not 
include  fadlrties  to  detect  and  handle  exceptions.  This  is  a 
serious  defecL 

L470H4  -  Typing 

According  to  Sommenrille,  "it  is  essential  that  a  high-level 
programming  language  with  strict  typing  be  used  for  system 
development.  Adiieving  fault-free  software  is  virtually 
impossible  if  low-level  programming  languages  with  limited  type 
checking  are  used." 

Discuss  the  "need  to  know"  principle.  This  should  be  used  to 
control  access  to  system  data.  Key  to  effective  information 
hiding  is  a  language's  typing  system.  Cite  Ada's  use  of  private 
types  to  ensure  that  the  details  of  a  data  structure’s 
implementation  is  inaccessible  beyond  where  it  is  defined. 

L470H5  •  information  hiding 

Languages  like  Ada  and  C-t'-t-  offer  direct  support  for 
information  hiding.  Refer  to  Sommerville  section  15.1.2  for  an 
excellent  discussion  of  data  typing. 

L470H6  -  Procedural  and  data  abstraction 

According  to  Mynatt,  a  ianguage  should  include  these  features 

i  Mechanisms  for  high-level  encapsulation  of  procedural 
abstractions  god  data  abstractions. 

ii  Distinction  between  the  specification  of  an  abstraction 
and  the  implementation  of  an  abstraction. 

iii  Mechanisms  to  protect  outside  access  to  encapsulated 
information. 

iv  Methods  for  importing  modules  from  other  sources. 

Tools  -  structure  editors,  debuggers,  programming 
environments,  package  libraries 

Maintenance 
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l.  Reuse  (libraries,  packages) 

m.  The  level  of  a  language's  support  for  object-oriented 
approaches  (e.g.,  direct  support  tor  the  definition  of  classes, 
inheritance,  encapsulation,  and  messaging)  is  becoming 
increasingly  important. 

Note  the  ongoing  debate  between  proponents  of  Ada  and  On 
the  Ada  side,  it  has  strong  typing  that  leads  to  greater  reliability  and 
maintainability  and  it  is  standardized  which  leads  to  true  portability. 
On  the  C-M-  side,  it  is  object-oriented  and  that  should  lead  to  ease  of 
development  and  reuse. 

L470H7 

Discuss  the  following  factors  affecting  the  quality  of  source  code. 

a.  Use  of  structured  coding  techniques. 

b.  Good  coding  style. 

i  Shorter  is  simpler. 

ii  Fewer  decisions  is  simpler. 

iii  Nested  logic  should  be  avoided. 

iv  Negative  logic  should  be  avoided. 

c.  Well-chosen  local  data  structures. 

d.  L47OH0  -  Well-written  Internal  comments. 

i  Program  headers. 

ii  Internal  module  headers. 

iii  Line  comments. 

e.  Readable,  consistent  source  code  format  and  identifier  naming. 

i  Vertical  white  space. 

ii  Horizontal  white  space  (indentation). 

iii  Readability  of  comments  (spelling,  grammar,  clarity) 

f.  Summarize  the  discussion  by  discussing  how  critical  the 
adoption  of  a  written  set  of  programming  standards  is  to 
enforcing  quality  code.  Call  attention  to  the  Ada  Quality  and 
Style  manual. 

g.  Point  out  also  that  well  designed  modules  (highly  cohesive, 
loosely  coupled)  are  easier  to  document.  Ask  why  and  discuss. 
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PROCEDimS: 

teachino  method  and  media: 


vocabulary  introduced: 
structured  programming 
syntax 
orthogonality 

INSTRUCTIONAL  MATERIALS: 


OYBTtlgfflte: 

L470H1 

L470H2 

L470H3 

L470H4 

L470H5 

L470H6 

L470H7 

L470H8 

liaodQuls: 


Active  support  from  implementation  language 
Pragmatic  factors  in  language  selection 
Features  language  should/must  support/possess  - 1 
The  case  for  strong  typing 
Features  language  should/must  support/possess  •  2 
Mynatt:  procedural  and  data  abstraction 
Factors  affecting  quality  of  source  code  - 1 
Factors  affecting  quality  of  source  code  -  2 


RELATED  LEARNING  ACTIViTiES: 
(labs  and  exercises) 

READING  ASSIGNMENTS: 

Mynatt  Chapter  5  (pp.  207-235) 
Mynatt  Chapter  6  (pp.  239-271) 


RELATED  READINGS: 

Pressman  Chapter16  (pp.  513-545) 

Schach  Chapter  11  (pp.  339-356,  369-381) 
Schach  Chapter  15  (pp.  469-489) 
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Active  Support  From 
Implementation  Language 


Good  code  can  be  written  in  any  ianguage,  even 
assembly  language. 


BUT,  it  is  much  easier  and  more  likely  if  the 
language  itself  actively  supports  the  production  of 
efficient,  reliable,  maintainable  software. 


7 


L470H1 


Pragimrtic  Factors  in  Osisction 

Dictated  by  client 


Existing  expertise/experience 
Language  used  in  other  projects 
Concurrency 
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Features  Language 
Should/MustSupport/Possess  - 1 


Modularity  The  partitioning  of  a  iarge  product  into 
modules 


Power  and  suitability 


Simplicity,  clarity,  orthogonaiity 


Simple,  consistent  syntax;  supportive  of  clear  code 
includes: 

Method  of  indicating  biocks 
Statements  format 
Ruies  for  identifier  names 

Structured  programming 


Exception  handiing 


Strong  typing 
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The  Case  For  Strong  Typing 


"...  it  is  essential  that  a  high-levei  programming 
ianguage  with  strict  typing  be  used  for  system 
deveiopment.  Achieving  fault-free  software  is 
virtually  impossible  if  low-level  programming 
languages  with  limited  type  checking  are  used." 

Sommerville 
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Features  Language 
Shoukl/MuM  Suppoit^Maesa  -  2 

Information  hiding 

Procedural  and  data  abstraction 

Tools 

Maintenance 

Reuse  (libraries,  packages) 

Support  for  object-oriented  approaches 
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Mynatt:  Procedural  and  Data  Abstraction 


To  adequately  support  procedural  and  data 
abstraction,  a  language  should  include: 


Mechanisms  for  high-level  encapsulation  of 
procedural  abstractions  aod  data  abstractions. 


Distinction  between  the  specification  of  an 
abstraction  and  the  implementation  of  an 
abstraction. 


Mechanisms  to  protect  outside  access  to 
encapsulated  information. 


Methods  for  importing  modules  from  other 
sources. 
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Factors  Affecting  Quality  of  Source  Code  - 1 

Use  of  structured  coding  techniques 

Good  coding  style. 

Shorter  is  simpler. 

Fewer  decisions  are  simpier. 

Nested  iogic  should  be  avoided. 

Negative  logic  should  be  avoided. 

Well-chosen  local  data  structures. 
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Factors  Affecting  Quality  of  Source  Code  -  2 

Well-written  internal  comments. 

Program  headers. 

Internal  module  headers. 

Line  comments. 

Readabie,  consistent  source  code  format  and 
identifier  naming. 

Verticai  white  space. 

Horizontai  white  space  (indentation). 

Readabiiity  of  comments  (speiling,  grammar, 
clarity) 
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UBCTUR6  NUMHBHI  048 

TQPIC(8)  F0R.UECIURE: 

Scheduling  software  projects 
Milestones 

Work  breakdown  stnictures 
Network  Scheduling  Techrtiques 
Introduction  to  Estimation  techniques 


INSTRUCTIONAL  QaJECIlYE(S): 

1.  Understand  deeeiopmerTt  milestones 

2.  Recognize  the  elemenls  of  a  work  breakdown  structure 

3.  Be  able  to  develop  a  PERT  chart 

4.  Understand  slatik  time  and  criticai  paths 

SET  UP.  WARM-UP: 

(How  involve  learner:  recaU.  review,  relate) 

At  this  point,  you  have  all  participated  in  ail  aspects  of  the  software 
development  process  and  have  experienced  some  of  the  difficulties  with  it. 
You  are  not  alone  in  this.  Show  GAO  overhead  L480H1.  Note  that  almost 
50%  of  the  contracted  software  was  not  used.  The  goals  of  software 
engineering  can  be  described  as  delivering  the  right  product,  on-time  and 
wKhin  budget.  Meeting  these  goals  requires  a  plan,  generally  called  a 
software  project  management  plan  (SPMP). 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

We  have  provided  a  basic  SPMP  for  each  of  your  projects.  Today  we  are 
going  to  look  at  how  to  develop  and  read  SPMPs.  We  will  also  see  a 
special  notation  used  for  SPMPs. 


CONTENTS: 

1.  There  are  several  unique  elements  in  software  that  make  the 
development  of  software  projects  more  difficult  than  the  development 
of  hardware  objects.  Many  authors  recognize  that  there  are  significant 
differences  between  hardware  and  software  that  make  the 
development  task  for  each  type  of  product  very  different.  Review  the 
differences  mentioned  on  L4^H2. 

a.  Reuse  is  aided  by  common  interfaces,  many  of  which  have 
been  legislated  by  engineering  societies,  e.g.,  the  standard 
electrical  plug. 


1 


Lecture  048 


b.  The  difference  in  the  tangible  nature  makes  it  more  difficult  to 
track  the  progress  of  the  development  of  software.  Hardware 
tends  to  conform  to  well  know  physical  laws.  Even  in  those 
cases  where  we  do  not  understand  the  laws,  hardware  can  be 
experientially  tested,  e.g.  a  scientist  grows  cracks  in  airplane 
wings  by  subjecting  them  to  specific  stresses  and  then  recalls 
those  planes  which  have  undergone  similar  stress. 

c.  A  significant  difference  between  hardware  and  software  is  the 
phase  in  the  development  process  where  errors  get  introduced. 
Most  hardware  errors  get  introduced  in  the  manufacturing 
process,  while  most  software  errors  get  introduced  in  the 
analysis  and  design  process. 


2.  Software  project  management  begins  with  the  completion  of  the 
requirements.  The  task  needs  to  be  defined  before  a  plan  can  be 
made.  Discuss  the  basic  steps  in  the  development  of  a  plan. 
Emphasize  that  even  the  SPMP  is  subject  to  revision.  Requirements 
are  input  to  the  SPMP.  L480H3 

L480H4 

3.  Divide  up  the  task-  people  have  used  the  term  milestones  to  indicate 
major  points  at  which  a  project  should  be  tracked.  We  know  some 
mayor  divisions  for  a  software  development  project.  These  milestones 
have  been  associated  with  major  project  deliverables  which  are  clearly 
defined,  e.g.,  2167a  has  a  series  of  clearly  defined  document 
deliverables.  When  dealing  with  relatively  small  projects  this  division 
of  the  system  is  adequate.  However  when  we  are  talking  about 
programming  in  the  large  and  large  projects  such  as  the 
environmental  control  software  for  the  space  lab,  there  is  too  much 
time  between  these  milestones  to  adequately  track  a  project.  There 
are  years  between  these  milestones.  Another  way  to  handle  this 
problem  is  to  break  the  major  milestones  down  into  smaller,  but  still 
discrete  and  measurable  units  of  work-  sometimes  referred  to  as  "inch 
pebbles".  The  smaller  the  degree  of  granularity  -the  time  required  to 
complete  one  of  these  task-  the  more  accurate  the  scheduling 
estimates  tends  to  be. 

The  milestones  arxi  inch  pebbles  are  discrete  events  that  mark  the 
completion  of  events.  These  are  distinguished  from  activities  that  take 
place  over  time.  Milestones  are  completions  of  these  project  activities. 
Activities  have  beginnings  and  ends  and  have  duration,  while 
milestones  are  points  in  time. 
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4.  We  can  divide  the  system  up  into  its  larger  phases  and  for  each 
phase  that  takes  longer  than  our  desired  granularity  we  can  further 
subdivide  the  task.  The  results  of  this  process  are  called  work 
breakdown  structures  (WBS)  or  discrete  pieces  of  work.  Within  a 
computer  system  work  breakdown  structures  are  very  detailed  and 
include  such  items  as:a  description  of  the  task,  who  is  responsible  for 
the  task,  what  resources  are  needed  to  accomplish  the  task,  etc. 

5.  Let  us  do  a  preliminary  work  breakdown  list  for  building  a  skyscraper. 
Ask  the  students  to  name  the  tasks  in  building  a  skyscraper.  List 
these  randomly  on  the  chalkboard.  This  kind  of  list  does  not  show 
interdependence  of  WBS  tasks.  Show  L480H6  overhead  as  your 
preliminary  list  and  explain  the  need  for  each  item.  Return  to  this 
overhead  after  you  have  worked  through  a  PERT  chart.  Ask  them  to 
identify  which  events  have  to  be  done  in  sequence  and  which  events 
can  be  done  concurrently.  One  way  to  display  these  relationships  is 
to  place  the  WBS  activities  on  an  graph  calied  a  vertex  activity  graph* 
the  activities  occur  at  the  vertices.  This  was  formalized  as  a  method 
by  the  Polaris  project  and  the  method  is  called  Performance  and 
Evaluation  Review  Technique  (PERT). 

We  can  impose  an  ordering  on  the  WBS  list  in  terms  of  what  things 
have  to  be  completed  before  others  and  what  is  our  estimate  of  their 
duration.  Show  activity  list  L480H7.  This  shows  the  dependencies 
for  each  task  in  the  prerequisite  column  and  the  duration  of  each  task 
in  the  time  column. 


L480H8 

6.  PERT  charts-There  are  many  ways  to  develop  PERT  charts.  One 
way  is  to  view  an  activity  as  a  set  of  parameters  consisting  of  the 
WBS  #,  the  earliest  possible  start  date  for  that  activity,  the  latest 
possible  start  date,  and  the  estimated  duration  of  the  task.  The  lines 
entering  a  graph  node  or  activity  represent  those  task  which  must  be 
completed  before  the  actMty  in  that  node  can  be  started. 

L480H9a  is  a  skeleton  PERT  chart  to  use  as  an  example.  L480H9b 
is  a  completed  PERT  chart  for  this  example.Begin  to  develop  the 
PERT  chart  on  the  board.  Fill  in  all  of  the  parameters  and  then  point 
out  those  places  where  there  is  no  difference  between  the  earliest 
possible  and  the  latest  start  time. 

L48OH10 

7.  Introduce  Critical  Path  Method  as  an  important  function  of  activity 
networks.  Define  the  critical  path  and  slack  time.  Discuss  how  any 
delay  in  critical  path  elements  will  delay  the  schedule.  Describe  how 
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this  process  indicates  how  iong  it  wiii  take  to  complete  a  project. 
L480H1 1  Summarize  the  definitions  and  discuss  this  overhead. 


8.  False  safety  factor-  Sometimes  we  think  that  the  way  to  meet  the 
schedule  d^rmined  by  a  PERT  chart  is  to  Just  add  some  time.  For 
example.  Sommerville  pg  503  "increase  the  estimate  to  cover 
anticipated  problems  and  add  a  contingency  factor  to  cover 
unanticipated  problems."  However  studies  have  shown  that  this  is  not 
an  affective  technique.  Adding  time  to  a  schedule  actually  makes  a 
project  take  longer  and  the  same  unexpected  surprises  occur  later  in 
the  project. 


9.  Once  a  PERT  chart  and  ite  accompanying  schedule  are  done.  The 
schedule  should  immedi^^y  be  reviewed  for  those  typical  items  that 
impact  a  schedule  but  are  often  forgotten.  How  will  the  vacation 
schedule  impact  the  availability  of  personnel?  How  long  will  it  take  to 
train  the  staff  on  the  new  system  or  CASE  tools?  What  other  projects 
are  planned  such  as  migrating  to  a  new  operating  system  in  the 
middle  of  your  project?  These  will  all  negatively  impact  the  project 
schedule.  What  is  the  budget  cycle  of  the  external  agency.  Many  of 
those  government  projects  which  were  not  delivered  were  funded  in 
September  but  were  not  re-funded  in  October,  the  beginning  of  the 
federal  governments  fiscal  year. 

10.  Discuss  the  two  standards  for  SPMPs  on  L48HD1  and  L48HD2. 

PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 
activity  networks 

CPM 

risk  analysis 
PERT 
slack  time 
critical  paths 
milestones 

work  breakdown  structures 


INSTRUCTIONAL  MATERIALS: 
overheads: 

L480H1  GAO  survey  of  software  contracted  for  by  government 
L480H2  Hardware  vs.  software  development 
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L480H3 

The  software  project  management  life  cycle 

L480H4 

Milestones  vs.  inch  pebMes 

L480H5 

Wbrk  breakckwvn  structure 

L480H6 

Planning  Exercise 

L480H7 

Activity  dependencies  -  tasks,  time,  and  prerequisites 

L480H8 

Contents  of  the  graph  node 

L480H9a 

Pert  chart  Outline 

L480H9b 

Pert  chart  Completed 

L48OH10 

Critical  path  method 

L480H11 

Critical  path  definition 

handouts: 

L48HD1 

IEEE  project  plan  oudine 

L48HD2 

NASA  prqect  plan 

RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 


READING  ASSIGNMENTS: 

Sommetville  Chapter  25  (pp.  477-492) 
Sommerville  Chapter  26  (pp.  495-507) 

RELATEDfjEADINGS: 

Ghezzi  Chapter  8  (pp.  415-440) 
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GAO  Survey  of  Software 
Procured  by  Government 


Category 

Amount 

(millions) 

Percent 

Used  as  delivered 

$0,119 

1 .75% 

Used  after  changes 

$0,198 

2.91% 

Used  but  reworked  or 
later  abandoned 

$1.3 

19.12% 

Paid  for  but  not 
delivered 

$1.95 

28.68% 

Delivered  but  NEVER 
successfully  used 

$3.2 

47.05% 

Total  cost  of 
software  surveyed 

$6.8 

100% 
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Hardware  veraua  Software  Development 


Reusable  Parts 

Tangible 

Physical  laws 
Experiential  standards 

Source  of  problems 
In  development 
In  maintenance 

Testing  Standards 
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The  Software  Project  Management  Life  Cycle 

I.  Prepare  the  SPMP 

1.  Examine  the  functional  and  non¬ 
functional  requirements 

2.  Divide  the  project  up  into 
understandable  units  and  required 
deliverables 

3.  Review  the  items  in  2.  and  add  to 
them  the  derived  deliverables 

4.  Build  work  breakdown  structures  for 
each  major  task 

5.  Develop  an  activity  network  for  the 
project  schedule. 

6.  Develop  an  SPMP 

II  Execute  the  SPMP 

1 .  Start  activities  according  to  the 
schedule 

2.  Frequently  monitor  the  project 
schedule 

3.  Modify  the  SPMP  or  internal  subplans 
as  needed. 
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Milestones  Versus  Inch  Pebbles 

2167a 

Requirements  Specification  Review 

Preliminary  Design  Review 

Detailed  Design  Review 

Code  and  Test 

System  Test 

Acceptance  Test 


Inch  Pebbles 


Activities  versus  Events 
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Work  Broakdowm  Structure 

Task  name  or  10:  (critical  path  ?) 

Description  of  task: 
Dependencies:(Predecessors) 

Project  members:(skills  need^) 

Duration:  Start  Date:  End  Date: 

Resources  Required: 

Entry  Criteria: 

Completion  Criteria: 

Responsible  Staff  member: 

Acceptance  Criteria: 

Exit  Criteria: 

Sign-off  person: 

Task  deliverables: 
validation  complete 
documents  complete 
reviewed 
CMS 

Risks: 

Risk  Plan: 


date_ 

date_ 

date_ 

date_ 
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Planning  Exercise 


Project:  Build  a  skyscraper: 

Tasks:  (WBSs) 

Fence  off  site 

Erect  Workshops 

Dig  foundaHon 

Install  on-site  concrete  plant 

Bend  reinforcing  rod 

Fabricate  steel  work 

Paint  steel  work 

Place  reinforcements 

Pour  foundation 

Erect  steel  work 

Place  a  tree 
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Activity  Dependencies 


Project  Build  a  building: 

Tasks  Time  Prereq. 

1  Fence  off  site  2  0 

2  Erect  Workshops  4  1 

3  Dig  foundation  6  1 

4  Install  on-site 

concrete  plant  4  1 

5  Bend  reinforcing  rod  3  2 

6  Feibricate  steel  work  7  2 

7  Paint  steel  work  3  6 

8  Place  reinforcements  5  3,5 

9  Pour  foundation  8  4,8 

10  Erect  steel  work  10  9,7 

1 1  Place  a  tree  0  10 
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Contents  of  ttw  Qraph  node 


WBS  task  id  number 


EST  (earliest  start  time) «  Max{pred(TIME)  + 

pred(EST)} 


Time  = 


anticipated  duration 
of  this  activity 


LST  (latest  start  time)  »  Min  {succ(LST)- 

TIME) 
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Exampte  P«tt  Chart  Outtina 


I 


Tine 


Crilieal  PMh  MMliocI  (OPM) 

Slack  time  s  LSI  •  EST; 

Critical  path  »  path  whose  slack  time  «  o. 

Time  to  complete  project 
=  sum  of  (max  of  (EST  (PRED  Time)  +  TIME) 
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The  critical  path  is  the  longest  path  through 
the  network  in  terms  of  the  total  duration  of 
tasks 

In  complicated  projects  many  "near 
critical"  teisks  and  paths  may  exist 

Delays  in  a  non-critical  path  task  may 
result  in  a  new  critical  path 

Lengthening  the  critical  path  lengthens  the 
project 


iuestlons  Answered  by  Critical  Path  Analysis 


What  is  the  minimum  elapsed  time  to 
complete  the  project? 


What  tasks  determine  whether  the  project 
is  completed  in  the  minimum  time? 

What  is  the  latest  time  we  can  start  a 
particular  activity  without  impacting  the 
overall  finish  time? 
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Title  Page 
Revision  Sheet 
Preface 

Table  of  Contents 
List  of  Figures 
List  of  Tables 


1 .  Introduction 

1 .1  Project  Overview 

1 .2  Project  Deliverabies 

1 .3  Evoiution  of  the  SPMP 

1 .4  Reference  materials 

1 .5  Definitions  and  Acronyms 


2.  Project  Organization 

2.1  Process  Model 

2.2  Organizational  Structure 

2.3  Organizational  Interfaces 

2.4  Project  Responsibilities 
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3.  Managerial  Process 

3.1  Management  Objectives 

and  Priorities 

3.2  Assumptions,  Dependencies, 

and  Constraints 

3.3  Risk  Management 

3.4  Monitoring  and  Controlling 

Mechanisms 

3.5  Staffing  Plan 

4.  Technical  Process 

4.1  Methods,  Tools,  and  Techniques 

4.2  Software  Documentation 

4.3  Project  Support  Functions 

5.  Work  Elements,  Schedule,  and  Budget 

5.1  Work  Packages 

5.2  Dependencies 

5.3  Resource  Requirements 

5.4  Budget  and  Resource  Allocation 

5.5  Schedule 


Additional  Components 
Index  (optional) 
Appendices  (optional) 
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1.0  Introduction 

1.1  Identification 

1.2  Scope 

1.3  Pur^se 

1 .4  Organization 

1.5  Objectives 

1 .6  Program  Constraints 

1 .7  Program  Software  Scheduies 

1 .8  Program  Controls 
2.0  Applicable  Documents 

2.1  Reference  Documents 

2.2  Information  Documents 

2.3  Parent  Documentation 
3.0  Resources  &  Organization 

3.1  Project  Resources 

3.1.1  Contractor  Facilities 

3.1.2  Government  Furnished 
Equipment,  Software  &  Services 

3.1 .3  Personnel 

3.2  Responsibilities 

3.3  Paneis 

3.3.1  Review  Paneis 

3.3.2  Advisory  Paneis 

3.4  Software  Development 

3.4.1  Organizational  Structure 
Software  Development 


NASA-Sfw-DID-Ada  (2); 
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3.4.2  Personnel  -  Software 
Development 

3.4.3  Resources  -  Software 
Development 

3.4.4  Software  Development  Tools, 
Techniques,  Methodologies 

3.4.5  Software  Environment  Section 

4.0  Life-Cycle  Management 

4.1  Concept  and  Project  Definition 

4.2  Software  initiation 

4.3  Software  Requirements  Definition 

4.4  Software  Preliminary  Design 

4.5  Software  Detailed  Design 

4.6  Software  Implementation 

4.7  Software  and  System  Integration  and 
Testing 

4.8  Software  Acceptance  Testing 

4.9  Sustaining  Engineering 
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5.0  Management  Controls 

5.1  Engineering  Master  Schedules  and  Risk 
Management 

5.1 .1  Activities 

5.1 .2  Activity  Network 

5.2  Engineering  Master  Schedule  Reviews 
and  Reporting  Policies 

5.3  Risk  Management 

5.3.1  High  Risk  Areas 

5.3.2  Technology  Risks 

5.3.3  Disaster  Risks  and  Recovery 

5.4  Status  and  Problem  Reports 
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6.0  Software  Support  Environment 

6.1  Software  Development 

6.2  Software  Acquisition 

6.3  Software  Integration 

6.4  Operation  and  Maintenance 

6.5  Software  Tools 

7.0  Software  Product  Assurance 

7.1  Software  Configuration  Management 

7.2  Software  Independent  Verification  and 
Validation 

7.3  Software  Security 

7.4  Software  Product  Assurance 

7.5  Software  Interface  Definition  and  Control 

7.6  Waivers  to  SPMP  Policies  and 
Procedures 

7.6.1  Permanent  Waivers 

7.6.2  Temporary  Waivers 

7.6.3  Tool  and  Testbed  Waivers 

8.0  Notes 
9.0  Appendices 
1 0.0  Glossary 
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CCXX>MO 

Lines  of  code  estimation  techniques 
Function  Points  and  iines  of  code 


iNSTRUCTiONAL  OBJECTtVEfSi: 

1.  Use  CCXX)MO  equations 

2.  Do  a  function  point  analysis 

3.  Oeveiop  other  function  point  metrics 


SET  UP.  WARM-UP: 

(How  involve  learner:  recall,  review,  relate) 


We  have  seen  the  difficulties  that  artees  in  trying  to  correctly  schedule  a 
software  project  artd  the  aUccation  of  resources  needed  for  its  development. 
These  resources  have  to  be  paid  for.  Most  of  us  want  to  know  how  much 
something  is  going  to  cost  before  we  order  it.  Software  is  no  difterent.  We 
would  like  to  know  how  much  we  are  going  to  pay  for  software  before  we 
purchase  it.  This  is  no  problem  for  packaged  software;  we  simply  look  at  the 
price  on  the  box.  but  how  do  we  determine  the  cost  of  software  which  has 
not  yet  been  developed  or  even  been  thought  of  before.  What  do  you  say 
when  the  president  of  the  United  States  tells  you  she/he  wants  a  system  that 
will  let  everyone  vote  in  federal  elections  from  their  homes  and  asks  you  how 
much  will  it  cost  to  develop  a  "Home  Voting  and  tabulating  system"?  How 
can  you  determine  what  it  would  cost  to  develop  the  project  you  have  just 
competed? 


(Learning  Label-  Today  we  are  going  to  learn  ...) 

There  are  reasonable  ways  to  approach  this  problem  of  estimating  the  cost 
of  developing  software.  Today  we  shall  look  at  two  of  them  -  The 
Constructive  Cost  Model  (COCOMO)  and  Function  Point  Analysis. 


CONTENTS: 

1.  COCOMO  is  a  series  of  formulae  which,  using  an  estimate  of  the  total 
number  of  lines  needed  for  the  product,  pr^uoes:  cost  estimates, 
scheduling  estimates  and  manpower  requirements  for  each  phase  of 
the  life  cycle. 

L490H1 

2.  Describe  the  origin  of  COCOMO  in  a  business  environment  and 
describe  how  it  was  empirically  derived.  This  is  important  to  follow  up 
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on  so  that  the  students  understand  that  CCXX)MO  and  most  other 
estimation  technique  can  be  empirically  calibratad  for  better 
accuracy.  Although  it  does  not  presuppose  a  perfect  environment. 
COCOMO  makes  several  assumptions  about  the  development 
environment  of  the  project  being  estimated.  Review  these 
presumptions. 


3.  COCOMO  does  not  make  the  mistake  of  presuming  that  all  estimates 
start  from  the  same  point.  Sometimes  a  rather  quick  estimate  is 
needed  beoed  on  relatively  little  detail.  This  is  a  Basic  estimate. 
Discuss  the  intermediate  level  of  detail  used  for  an  estimate  and  use 
this  as  an  opportunity  to  discuss  the  different  project  cost  drivers  med 
for  an  intermediate  estimate.  The  students  find  it  easy  to  understand 
how  slow  turn  around  time  and  high  reliability  requirements  impact 
software  development  time.  Time  discussing  the  cost  drivers  is  well- 
spent. 


4.  After  the  discussion  of  cost  drivers  it  is  easy  for  the  students  to 
understand  the  impact  of  the  different  development  environments. 
These  environments  represent  a  scale  of  difficulty.  The  software 
development  process  is  more  stable  and  easier  to  understand  and 
control  in  an  organic  environment. 

a.  The  organic  environment  is  characterized  by  a  thorough 
understanding  of  the  product  and  product  objectives,  extensive 
experience  with  related  systems,  limited  pre-defined 
requirements,  limited  commitment  to  externally  defined 
interfaces,  minimal  need  for  innovation  and  a  low  need  for  an 
early  completion  date. 

b.  You  should  plead  ignorance  about  the  origin  of  the  label  "semi¬ 
detached".  The  semi-detached  development  environment  is 
between  the  organic  and  the  embedded  environment.  The 
semi-detached  environment  requires  considerable 
understanding  of  project  objectives,  experience  with  related 
systems,  need  to  meet  predefined  requirements,  and  need  for 
conformance  to  external  interfaces.  It  also  involves  some 
concurrently  developed  hardware  and  some  need  for 
innovation. 

c.  Embedded  develofiHnent  must  meet  predefined  requirements 
conform  to  external  interfaces  and  requires  concurrently 
developed  hardware.  It  also  requires  considerable  innovation 
and  has  a  high  need  for  early  completion. 
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L490H2 

5.  Discuss  COCOMO  as  almost  a  single  driver  estimation  tool  which 
provides  equations  for  each  development  environment  and  the  only 
variable  is  delivered  source  instructions(DSI).  Put  off  any  discussion 
for  awhile  about  how  you  derive  the  number  of  DSI.  Work  through 
each  of  the  person-month  equations.  Carefully  distinguish  between 
the  person  months  (or  effort  required)  and  the  time  to  develop(TDEV) 
the  software  or  the  period  of  time  in  which  that  effort  can  be 
squeezed.  Go  through  the  TDEV  equations. 


6.  Other  results-  show  that  it  is  relatively  easy  to  determine  the  average 
number  of  personnel  needed  during  the  life  of  the  project  -PM/TDEV- 
but  that  this  does  not  tell  you  how  many  people  you  need  during  any 
particular  phase.  Introduce  the  Rayleigh  Cunre  here  as  a  mean  of 
determining  how  many  people  you  need  for  each  phase  of  the  life 
cycle. 


7.  An  example  of  how  to  calibrate  COCOMO  is  given  in  the  Ada 
modifications  to  COCOMO  which  were  also  done  by  Barry  Boehm. 
L490H3 


8.  a  major  criticism  of  COCOMO  is  that  it  is  difficult  to  initially  estimate 
line  of  code  before  a  system  is  actually  written.  Function  points  is  one 
way  to  determine  DSI.  When  you  introduce  function  points  (FP)  be 
sure  to  emphasize  that  FP  is  a  dimensionless  number.  It  does  not 
really  count  "FUNCTIONS'. 

a.  Go  over  the  general  FP  equation.  Then  discuss  how  they 
derive  the  sum  of  functional  factors. 

L490H5 

b.  Show  the  chart  indicating  how  to  adjust  the  complexity  of  the 
function  points  and  derive  a  total  L490H4.  This  provides 
some  discrimination  among  type  of  inputs  and  outputs  which  is 
based  on  complexity. 

L490H6 

c.  Then  show  the  diart  r  degrees  of  influence  and  weighting 
factors  L490H7. 

d.  Work  through  a  set  of  numbers  and  arrive  at  a  FP.  Ask  the 
student  what  this  number  represents.  They  will  have  trouble 
coming  up  with  an  answer.  Make  dear  that  this  is  a  number 
that  can  be  used  to  compare  software  projects  if  the  same 
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mechanism  used  on  both  projects  to  derive  function  points. 

L490H8 

6.  Uses  of  Function  points-  They  can  be  used  as  a  productivity  measure 
or  a  quality  test .  We  started  to  look  at  function  points  as  a  way  to 
determine  the  lines  of  code  that  a  system  might  have  before  the  code 
was  even  written.  Using  past  experience  we  have  determined  that  the 
lines  of  code  that  it  takes  per  function  point  varies  from  language  to 
language.  A  correlation  between  function  points  and  lines  of  code,  for 
one  developinent  environment,  is  shown.  If  it  is  estimated  that  a 
project  will  take  200  function  points  and  it  is  being  written  in  Ada  then 
it  will  take  approximately  14400  lines  of  code.  This  lines  of  code 
approximation  can  be  us^  in  the  COCOMO  equations. 


9.  Emphasize  that  these  numbers  are  approximations  and  are  different 
for  different  development  environments.  But  these  values  can  be 
calibrated  for  any  consistent  development  environment. 

PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 
COCOMO 

Person-month  equations 
Time  of  development  equations 
Function  points 
Weighting  factors 
Degrees  of  influence 


INSTRUCTIONAL  MATERIALS: 


overheads: 

L490H1 

COCOMO 

L490H2 

COCOMO  equations 

L490H3 

Ada  modifications  to  basic  COCOMO 

L490H4 

How  to  determine  code  size 

L490H5 

Functional  point  counting 

L490H6 

Degrees  of  influence 

L490H7 

Weighting  factors 

L490H8 

Additional  function  point  metrics 

handouts: 
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RELATED  t^ARMlWB  *C1 
(libs  and  axarcitM) 


lES: 


Lab  037  •  Function  Points 

BSAPINQ  ASStQNMENTS: 

SommarvMe  Chapter  27  (pp.  511-533) 
Mynatt  Chapter  1  (pp.  17-27) 

RELATED  READINGS: 

Ghezzi  Chapter  8  (pp.  415-433) 
Pressman  Chapter  3  (pp.  83-89) 
Schach  Chapter  8  (pp.  212-215) 
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COCOMO 


Assumptions  of  the  Basic  CCX^OMO  Model: 
Requirements 
Low  volatility 
Good  S.E.  practice 
Good  management 

Three  ieveis  of  detail: 

Basic  - 

Intermediate  - 

Detaiied  - 

Three  deveiopment  environments: 

Organic  - 
Semi-detached  - 
Embedded  - 

DSi: 

Deiivered 

Source 

Instructions 
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COCOMO  Equations 

CCX)OMO  Person-month  Equations: 

Organic:  PM  =  2.4  *  KDSP  “ 

Semi-detached:  PM  =  3.0  *  KDSI’ 
Embedded:  PM  =  3.6  *  KDSP^ 

COCOMO  Time  of  Development  Equations: 
Organic:  TDEV  =  2.5  *  (PM)““ 

Semi-detached:TDEV  =  2.5  *  {PM)“” 
Embedded:  TDEV  =  2.5  *  (PM)0.32 

Full-time  Software  Personnel  =  PM/TDEV 

Work  distribution: 
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Ada  ModWcatlona  to  Basic  COCOMO 

Assumes  smaller  teams  initially 
Longer  design  period 

PM  =  2.8  *  KDSi^ 

TDEV  =  3  *  PM°“ 

PM  for  PD,  DD,  CUT,  iT  = 

PM  *  (.23,  .29,  .22,  .26) 

TDEV  for  PD,  DD,  CUT,  iT  = 

TDEV  *  (.39,  .25,  .15,  .21) 


8 


L490H3 


How  To  Determine  Code  Size 


Function  Points  = 

Sum  of  Functional  Factors  * 

[0.65  =  0.01  *  Sum  of  Weighting  Factors] 

Five  Functional  Factors 
Number  of  user  inputs 
Number  of  user  outputs 
Number  of  user  inquiries 
Number  of  files 
Number  of  external  interfaces 
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- Intrlntle  Slz»  of  Tatk"- 

(For  Productivity  Studies) 


Technical 

Complexity 

Adjustment 

B  Batch  V8  on-line 
a  Performance 
B  Ease  of  use 


Environmental 

Factors 

Project 

management/Risk 
People  skills,  etc. 
Methods,  Tools, 
Languages 


Unadjusted  Functional  Point  Counting 

Level  of  Information  Processing  Function 
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Technical  Complexity  Factor 


im 

Characteristic 

13 

^9 

Characteristic 

El 

Cl 

Data  communications 

C8 

On-line  update 

■ 

C2 

Distributed  functions 

C9 

Complex  processing 

C3 

Performance 

CIO 

Re-usability 

C4 

Heavily  used  configuration 

C11 

Installation  ease 

C5 

Transaction  rate 

C12 

Operational  ease 

C6 

On-line  data  entry 

C13 

Multiple  sites 

C7 

End  user  efficiency 

C14 

Facilitate  change 

Total  degree  of 
influence 

8==^ . ^ - i.  ■  »  ■  ^ 

■ 

TC^  =  0.65  +0.01  X  (Total  Degree  of  Influence) 


TCF- 

Technical 

complexity 

factor 

Di  Vaiues 

Dl  - 

Degree  of 

Not  present 

influence 

or  no  influence  =  0 

FP- 

Function  points 

insignificant  influence  :=  1 

UFP- 

Unadjusted 
function  points 

Moderate  influence  =  2 

Average  influence  »  3 

Significant  influence  =  4 

Strong  influence, 
throughout  >  5 

Thus  each  degree  of  influence  is  worth  1  percent  of  a  TCF  which  can  range  from 
0.65  to  1.35. 

The  intrinsic  relative  system  size  in  Function  Points  is  computed  from 

FP’s  -  UFP's  X  TCF 

Function  points  are  therefore  dimensionless  numbers  on  an  arbitrary  scale. 
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Weighting  Factors 


Does  the  system  require  reliable  backup  and 
recovery? 

Are  data  communications  required? 

Are  there  distributed  processing  functions? 

Is  performance  critical? 

Will  the  system  run  in  an  existing,  heavily 
utilized  operational  environment? 

Does  the  system  require  on-line  data  entry? 

Does  the  on-line  data  entry  require  the  input 
transaction  to  be  built  over  multiple  screens  or 
operations? 

Are  conversion  and  installation  included  in  the 
design? 

Is  the  system  designed  for  multiple 
installations  in  different  organizations? 

Is  the  application  designed  to  facilitate  change 
and  ease  of  use  by  the  user? 
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Additional  Function  Point  Metrics: 


Productivity  =  Function  Points/  Person-Months 
Quality  =  Errors/Function  Point 
Cost  =  $/Function  points 
Documentation  =  Pages/Function  Point 


Correlations  between  function  points  and  iines  of 
code: 

Basic  assembier  360 

Macro  assembler  21 3 

C  128 

COBOL  105 

FORTRAN  105 

Pascal  80 

Ada  72 

Basic  64 

4GL  25 
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Assessment  of  projects 


INSTRUCTIQNAl  QBJECTIYSIS): 

(indicate  learner  behavior  expected  or  learning  outcome) 

1 .  Encourage  students  to  compare  different  development  methodologies 

2.  Encourage  students  to  compare  different  development  environments 

3.  Review  significance  of  each  phase  of  the  devekipment  life-cycle 


SET  UP.  WARM-UP: 

(How  involve  learner,  recall,  review,  relate) 

We  have  completed  work  on  several  different  types  of  projects,  using 
different  methodologies  and  team  organizations.  Each  of  these  differences 
impact  not  only  the  final  product  developed  but  also  the  process  of 
development. 


(Learning  Label-  Today  we  are  going  to  learn  ...) 

Now  that  you  have  completed  the  project  work  for  this  course.  We  should 
take  some  time  to  re-examine  some  of  the  processes  we  have  been  through. 


CONTENTS: 

1.  Introduce  a  series  of  discussions  on  the  various  methodologies. 
Project  1  employed  a  structured  methodology,  while  project  2  used  an 
object-oriented  methodology.  Would  an  obj^-oriented(O-O) 
methodology  have  been  better  for  project  1?  Try  to  direct  the 
discussion  away  from  the  questions  of  how  hard  it  would  be  to  learn 
object-oriented  methodologies  quickly  and  direct  the  discussion  to  the 
appropriateness  of  the  0-0  methodology.  Get  them  to  articulate  the 
difference  between  the  methodologies. 


2.  The  projects  differed  in  terms  of  structure  and  the  communications 
required.  Discuss  whether  the  structure  imposed  on  the  extended 
project  should  have  been  used  on  the  small  project  as  well.  This 
opens  a  good  discussion  on  the  positive  and  negative  impacts  of 
controlling  disciplines-  CM,  SQA,  V  &  V.  At  some  point  they  will  start 
to  talk  afa^  the  prcMsIems  of  team  interactions.  Direct  this  to  an  issue 
of  the  importance  of  good  team  communication  and  away  from 
question  of  conflicting  personalities. 


3.  Questions  of  effective  intra-team  communications  can  be  discussed 
here  along  with  the  importance  of  dear  and  baselined  documents. 
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This  can  be  used  to  review  each  stage  of  the  Ufe  cycle. 

4.  An  assessment  which  we  used  in  a  previous  class  is  included  as 
instructor  notes.  The  questions  we  asksd  can  be  used  to  develop  you 
own  assessment  questions. 

PROCEDURE: 

teaching  method  and  media: 


vocabulary  introduced: 


INSTRUCTIONAL  MATERIALS: 
overheads: 

handouts: 

RELATED  LEARNING  ACTIVITIES: 
(labs  and  exercises) 


REAPING  ASSIGNMENTS: 

None 

RELATED  READINGS: 
None 
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instructor  Notes 


Software  Engtnaering  Survey 


In  an  effort  to  improve  the  structure  of  this  course  and  the  quality  of  its  instruction 
we  ask  that  you  complete  this  survey.  We  value  your  judgements.  Your  thoughtful 
responses  will  significantly  add  to  the  quality  of  this  course. 

This  questionnaire  is  a  significant  portion  of  the  final  examination.  You  will  get 
FULL  credit  for  this  question  simply  by  giving  us  your  thoughtful  responses. 


A  PROJECT  1  (Small  project  names) 

The  purpose  of  project  1  was  to  give  you  a  rapid  introduction  to  software 

engineering  and  to  let  you  quickly  experience  the  entire  software  lifecycle  by  taking 

a  small  project  from  requirements  through  implementation. 

1 .  Were  these  projects  appropriate  for  this  purpose? 

2.  The  team  organization  used  for  this  project  is  called  a  democratic  team.  Did 
this  organization  help  or  hinder  your  progress  on  the  project. 

3.  Would  it  have  helped  to  have  one  or  more  of  the  teachers  present  at  some 
of  your  team  meetings? 

4.  How  did  you  keep  track  of  what  tasks  had  to  be  done  and  whether  they  were 
done? 


B  PROJECT  2  (Extended  project  name) 

In  this  project  we  us^  a  "matrix  model”  of  team  organization. 

1 .  Did  the  experience  of  working  on  several  different  teams  during  the  project 
help  you  better  appreciate  the  additional  problems  in  developing  more 
complex  software?  Did  you  find  it  a  helpful  experience  to  work  on  several 
teams?  (In  the  matrix  structure  you  switched  teams  several  times.  How  did 
you  feel  about  that?) 

2.  Unlike  project  one,  here  you  had  to  interact  with  other  teams.  What  did  you 
think  of  this  experience? 

3.  One  of  the  modifications  we  are  considering  for  future  use  is  the 
establishment  of  a  "tools  team"  that  would  learn  all  the  CASE  software  tools 
and  provide  training  and  on-going  help  in  the  use  of  the  tools.  What  do  you 
think  about  this  idea? 
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4.  Another  modification  we  are  considering  for  future  use  is  the  establishment 
of  a  "user  interface  team"  that  would  be  responsible  for  the  user  manual  and 
the  design  of  the  user  interface.  What  do  you  think  about  this  idea? 

5.  Can  you  think  of  any  other  teams  that  might  be  helpful? 

6.  In  this  project  we  introduced  configuration  management.  In  what  ways  did 
this  help  your  work  on  the  project?  How  might  it  be  improved? 

7.  How  did  the  use  of  object-oriented  design  help  on  this  project? 

8.  There  were  two  different  software  project  management  plans  provided  to  you 
for  this  project.  Was  the  more  detailed  plan  (inch  pebbles)  more  help  to  you? 

9.  Some  people  say  it  is  very  hard  to  shift  from  a  structured  analysis  model 
(DFDs,  Context  Diagrams,  data  dictionary,  process  specifications)  to  an 
object-oriented  model. 

a.  How  did  the  requirements  list  and  the  structured  analysis  model  help 
you  to  make  the  transition? 

b.  How  did  our  discussion  of  Ada  and  our  explanations  of  the  object- 
oriented  model  help  you  make  this  transition? 


C  REVIEWS 

1.  We  required  a  number  of  reviews  (requirements,  preliminary  design,  test 
plan...)  as  the  projects  were  developing. 

a.  List  what  you  consider  the  major  strengths  of  the  in-class  reviews. 

b.  List  what  you  consider  the  major  weaknesses  of  the  in-class  reviews. 

c.  How  could  we  respond  to  these  weaknesses? 

2.  We  required  that  each  team  member  take  part  in  these  reviews.  How  did 
this  help  you? 

3.  We  are  thinking  of  assigning  some  students  who  were  not  part  of  the  team 
as  reviewers  for  each  presentation.  How  do  you  think  this  might  improve  the 
review  process? 


4 


Lecture  050 


D  TEAMS 


1.  In  project  one  we  used  a  democratic  team,  in  project  two  a  matrix 
organization,  and  in  the  maintenance  exercises  a  chief-coordinator 
organization.  Which  structure  did  you  find  the  most  productive?  Which 
structure  did  you  find  the  most  comfortable? 

2.  We  assigned  students  to  teams  based  in  part  on  student  input.  How  do  you 
think  we  should  assign  students  to  teams? 


E  Ada 

1.  Was  it  helpful  to  implement  the  targe  project  in  a  new  language?  (Try  to 
separate  your  answer  from  the  question  of  the  adequacy  of  our  current  Ada 
environment) 

2.  Did  the  use  of  Ada  help  you  see  the  application  of  software  engineering 
principles  in  specifications?  in  design? 

3.  Ada  was  gradually  integrated  into  this  course;  first  by  showing  specification 
examples  and  then  by  showing  program  segments.  We  read  through  code 
in  class.  We  revisited  Ada  code  several  times  in  increasing  depth.  Was  this 
technique  (called  program  reading)  a  helpful  way  to  introduce  Ada  as 
oppos^  to  simply  studying  syntax? 


F  EVALUATION 

1.  Please  comment  on  the  peer  evaluation  process  used  in  assessing  the 
projects. 

2.  Were  the  examinations  fair  and  did  they  adequately  cover  the  material?  How 
would  you  like  to  change  the  s^ucture  and  content  of  these  tests. 

3.  Can  you  think  of  any  other  ways  we  might  use  to  improve  our  evaluation  of 
your  work  in  the  course? 

4.  We  gave  a  variety  of  feedback  as  the  projects  progressed:  first  draft  reviews, 
review  evaluations,  meetings  with  customers  or  users  etc.  Was  this 
adequate  and  helpful?  Were  there  some  other  things  we  could  have  done 
to  h^  your  team's  progress. 

5.  Were  the  software  project  management  plans  for  the  projects  adequate? 
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G  OVERALL  COURSE  APPROACH 


1 .  This  course  involved  three  professors.  How  was  this  helpful  and  how  was 
it  not  helpful?  Would  you  like  to  see  other  classes  leam-taught”? 

2.  One  of  the  major  goals  of  this  course  was  to  give  you  experience  in  a  real 
world  software  development  environment  functioning  in  a  variety  of  roles  and 
working  with  a  variety  of  people. 

a.  Do  you  think  that  the  course  sxlequateiy  reflected  the  real  world? 

b. .  Do  you  feel  that  this  course  helped  prepare  you  for  working  in  an 

industrial  environment? 

c.  How  would  you  modify  the  types  and  the  number  of  software  projects 
to  help  accomplish  this  goal. 

3.  In  our  spiral"  approach  we  briefly  introduced  a  subject  in  one  lecture,  then  in 
later  lectures  we  provided  additional  detail.  In  some  cases  subjects  were 
revisited  several  times,  each  in  increasing  depth,  e.g.,  testing,  design,  or 
configuration  management.  Do  you  think  this  approach  helped  in  building 
your  understanding? 

4.  The  spiral  approach  was  also  used  in  the  projects.  Did  this  approach  help? 
For  example,  would  the  extended  project  have  been  harder  for  you  to  do  if 
you  had  not  first  done  a  smaller  project? 

5.  Was  the  coordination  of  the  lecture,  projects,  and  readings  effective? 

6.  List  what  you  consider  the  major  strengths  of  this  course 

7.  List  what  you  consider  the  major  weaknesses  of  this  course 

8.  How  might  we  still  meet  our  goals  and  respond  to  these  weaknesses? 


H  TEXTBCX)KS 

1 .  Comment  on  the  value  of  the  Sommerville  textbook  to  the  course. 

2.  Comment  on  the  value  of  the  Mynatt  textbook  to  the  course. 

3.  Comment  on  the  value  of  the  Benjamin  textbook  to  the  course. 


If  there  is  anything  else  you  want  to  comment  on.  tfien  please  do? 
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Real-World  S<tftwafe  Engineering 

M  LABS 


a.  Liboralory  IlMlinQt. 

Structured  labs  aiB  utMzad  throughout  th«  oouTM.  By  structured  iabe  we  mean  meetings 
held  at  the  same  time  as  regular  class  meetings  and  during  which  the  instructor  was 
present  providing  guidance  and  support  for  the  students*  eflbrts.  particuiarly  team  efforts. 

Laboratories  are  utilized  for  a  variety  of  activities,  most  of  which  are  directiy  relaled  to  the 
team  projects.  They  provide  opportunities  for  student  teams  to  meet,  for  instructor 
interaction  with  teams,  and  for  customer  or  user  interaction  with  teams.  Lab  activities 
included  organizationai  meetings,  customer  requests,  distribution  and  discussion  of  project 
materials  (e.g.  software  project  management  plan,  meeting  report  templates,  presentation 
guidelines  and  assessment  forms),  structured  exercises  on  methods  and  tools,  feedback 
to  teams  on  deliverabies  and  presentations,  formal  reviews,  code  inspections,  and 
"steering"  of  teams  where  necessary. 

The  amount  of  faculty  direction  varies  from  lab  to  lab.  Some  labs  consist  of  exercfoes 
where  the  student  interacts  directly  wifo  the  instructor.  Some  labs  are  used  to 
demonstrate  a  CASE  tool  that  is  being  used  for  a  segment  of  a  project.  Other  labs 
consist  primarily  of  team  meetings.  Less  structured  late  are  useful  when  deadlines  for 
major  deliverabies  approached.  These  labs  are  prknariiy  dedicated  to  team  meetings  to 
wo^  on  team  deliverables.  The  connection  of  the  lab  time  to  the  projects  is  further 
reinforced  by  having  reviews  of  team  deliverabies  during  lab  time. 

We  believe  it  is  essential  to  have  student  labs  scheduled  at  the  regular  dass  meeting 
times.  Students  have  no  conflicting  obligations  at  that  tfore  and  any  Mheduling  difficulties 
for  team  meetings  are  eliminated.  Equally  important  is  the  availability  of  the  instructor. 
The  instructor  is  an  immediate  resource  to  pro^  whatever  level  of  steering  is  necessary 
to  keep  the  team  effort  on  track.  While  the  instructor  should  avoid  micro-management 
of  team  projects,  he/she  must  be  wHHng  to  intervene  at  times.  Availability  of  the  instructor 
has  other  advaritages  as  weU.  Teams  are  sometimes  composed  of  personalities  that  do 
not  easily  coexist.  The  students'  knowledge  that  the  instnjctor  is  dose  by  helps  to 
minimize  the  eruption  of  overt  hostilities.  Your  availability  to  the  students  reinforces  the 
notion  that  you  lod  they  are  working  toward  a  single  goal  -  the  development  of  a 
successful  software  prpj^ 

Be  flexible  with  lab  time.  Use  it  to  keep  the  projects  on-track.  Always  provide  some 
guidance  for  the  lab.  You  must  do  what  you  can  to  avoid  the  tendency  some  students 
have  to  tNnk  that  lab  time  is  Just  an  opportunity  to  leave  early.  Your  presence  in  the  lab 
or  being  readily  available  during  iabe  will  effedively  minimize  this  attitude. 


b.  Introduction  to  lab  forma 

The  lab  form  is  similar  to  the  lecture  form  and  provides  a  consistent  structure  for  each  of 
the  labs.  Each  lab  description  consbte  of  the  following  sections. 

LAB  NUMBER  -  The  labs  are  numbered  sequentially  and  the  number  is  used  to 
cross  reference  lectures  and  laboratories. 

TOPICfS^  FOR  LAB  -  These  usually  refer  to  the  projects  and  indicate  the  specific 
activity  and/or  project  deliverable  to  which  the  lab  is  related. 

INSTRUCTIONAL  OBJECTIVEfS^  -  Again,  these  usually  refer  to  the  projects  and 
are  generally  stated  in  terms  of  behavioral  goals. 

ASSOCIATED  LECTURE  NUMBER  -  This  identifies  the  particular  lecture  with 
which  this  lab  is  associated.  In  many  cases  these  labs  relate  the  lecture  material 
to  the  practical  concerns  of  their  projects. 

PRyEDURE  •  A  step-by-step  description  of  the  activities  to  be  conducted  is 
provided.  Handouts  or  overheads  are  referenced  where  used. 

ASSOCIATED  HANDOUTS  -  A  list  of  any  handouts  used  during  the  lab  is 
provided.  A  copy  of  each  handout  for  a  lab  immediately  follows  the  lab  form. 


c.  Labs 

The  lab  forms  for  the  individual  laboratories  follow. 
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LAB  NUMBER:  001 


TQPiQ(S)  FOa  LAB: 

Customer  requests 

Small  projects  team  organization 

Requirements 

INSTRUCTIONAL  OBJECTIVEiSI: 

1 .  Understand  specific  customer  request. 

2.  Meet  fellow  team  members  for  small  project. 

3.  Develop  an  abstract  and  list  of  requirements  for  the  small  team  project. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  003 

SET  UP,  WARM-UP: 

Recall  in  the  preceding  lectures,  you  were  introduced  to  the  process  of  developing 
a  requirements  for  a  requested  system  and  typical  problems  related  to  customer 
requests.  We  characterized  the  process  of  devetoping  good  requirements  as  one 
of  extraction.  We  also  talked  about  the  importance  d  understanding  the  system 
and  developing  and  specifying  the  requirements.  Today  you're  going  to  become 
a  member  of  a  project  team,  listen  to  a  customer  who  wants  your  team  to  develop 
a  system,  and  begin  work  on  developing  the  system  requirements. 

PROCEDURE: 

1 .  HANDOUT(S)  •  Project  descriptions. 

The  instructor(s).  role-playing  as  customer(s),  present  their  requests  to  the 
dass.  The  request  is  in  the  form  of  a  written  narrative  description  and  an 
oral  description.  Any  questions  are  discussed  and  answered  from  a 
customer  perspective.  It  is  important  to  resist  the  tendency  to  deal,  as  the 
customer,  with  technical  questions;  the  customer  has  domain  expertise  but 
not  software  engineering  expertise.  Students  have  not  yet  been  assigned 
to  teams  or  projects.  All  students  listen  to  all  customer  requests  at  this 
point  [Note  -  a  paper  entitled  "Bringing  the  Customer  into  the  Classroom” 
is  induded  in  the  projects  section  of  this  packet] 

2.  HANDOUT  -  Software  project  management  plan  (SPMP) 

Discuss  the  plan  with  particular  attention  to  configuration  items  (CIs). 
presentations,  and  schedule. 

3.  HANDOUT  -  Small  project  team  and  project  assignments 

Announce  and  distribute  the  project  team  and  project  assignments.  Note 
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that  no  organizational  structure  is  imposed;  a  democratic  team  organization 
is  implied.  Teams  are  encouraged,  as  a  first  order  of  business,  to 
determine  some  times  when  they  can  all  meet.  Have  the  team  fill  out  a 
contact  sheet  containing  the  name  and  phone  number  of  each  team 
member. 

4.  HANDOUT  -  Team  meeting  report  template 

Inform  the  teams  that  a  record  is  to  be  submitted  for  each  team  meeting. 
The  form  provided  is  to  be  used.  At  the  first  class  meeting  of  each  week 
teams  are  to  submit  their  meeting  records  for  each  meeting  from  the 
previous  week.  Make  the  templates  available  in  electronic  form. 

5.  Teams  are  given  the  remainder  of  the  period  to  meet  and  begin 
development  of  a  list  of  requirements  (CI-1).  Their  customer  is  available  for 
the  remainder  of  the  class  period  to  answer  questions  regarding  the 
requested  system. 

HANDOUT  -  disk  with  client  request 

Each  team  is  provided  with  a  disk  containing  the  preliminary  client  request. 
This  will  be  refined  for  the  fiiet  configuration  item  (see  SPMP). 


ASSQ.C.1ATED.IHANDQUIS: 

1 .  Project  description(s)  •  preliminary  client  request 

2.  Software  Project  Management  Plan  (SPMP) 

3.  Team  and  project  assignments 

4.  Disk  containing  preliminary  client  request 

5.  Template  for  team  meeting  records 
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A  system  is  needed  to  control  a  kiosk  vending  machine  that  consists  of  three 
apparently  separate  vending  machines  that  are  actually  under  common  control.  The 
kiosk  has  three  walls,  each  wall  housing  one  vending  machine.  Each  machine  can 
dispense  up  to  32  different  items  and  has  its  own  coin  slot,  dollar  bill  slot,  and 
selection  panel.  The  coin  slots  accept  quarters,  dimes  and  nickels.  Thn  dollar  bill 
slots  accepts  only  one-dollar  bills.  The  selection  panels  consist  of  a  series  of  buttons, 
each  showing  a  graphical  representation  of  the  item  to  which  the  button  corresponds 
or  an  "empty"  indicator. 

To  use  any  of  the  machines,  a  customer  enters  money,  presses  on.  or  more  buttons 
on  the  selection  panel,  and  then  presses  a  "dispense"  button.  Assuming  sufficient 
money  has  been  entered,  the  selected  items  are  dispensed  and  the  correct  change 
returned.  A  customer  can  cancel  a  transaction  at  any  time  prior  to  hitting  the 
"dispense"  button  and  his/her  money  is  returned.  If  a  customer's  requests  cannot  be 
honored,  his/her  money  is  also  returned  automatically. 

All  three  machines  are  to  have  a  common  control  system  that  keeps  track  of  each 
machine's  strtus  including  the  total  amount  of  money  it  has  taken  in,  and  the  number 
of  items  dispensed  (for  each  of  the  32  different  items).  The  money  supply  and  money 
input  is  shared  by  the  three  machines  and  the  system  must  keep  track  of  the  number 
of  coins  it  has  (quarters,  dimes,  and  nickels),  and  number  of  dollar  bills  it  has. 

A  maintenance  operator  services  the  kiosk  frequently.  The  operator  must  be  able  to 
request  a  report  of  the  kiosk  status  as  well  as  the  status  of  any  of  the  individual 
machines.  The  operator  must  also  be  able  to  restock  the  machines,  reprice  items, 
and  replenish  and  collect  money. 

There  are  several  mechanical  functions  that  can  go  awry  and  the  existence  of  these 
problems  are  indicated  by  an  alarm  which  is  transmitted  to  the  operator's  pager. 

Alarm  conditions  always  indicate  the  machine  involved  and  the  particular  condition. 
Conditions  include  a  stuck  item,  stuck  coin  or  dollar  bill  slot,  machine  low  on  money  or 
type  of  change,  machine  out  of  money,  machine  out  of  particular  items,  and  machine 
or  kiosk  door  open.  The  operator  needs  the  ability  to  turn  the  alarm  indicators  off. 
Stuck  items  or  coins  disable  the  particular  machine  until  it  is  serviced.  The  machine 
out  of  money  condition  disables  the  kiosk  until  it  is  serviced.  A  problem  analysis 
report  is  generated  monthly. 
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PROJECT  DESCRIPTION:  GAZEBO  LOTTERY  SYSTEM 


A  small  town  has  decided  to  operate  a  local  lottery.  A  software  system  is 
needed  to  control  it.  Housed  in  a  gazebo  in  the  center  of  the  town  square,  it  consists 
of  three  apparently  separate  lottery  ticket  machines  that  are  actually  under  common 
control.  A  structure  inside  the  gazebo  has  three  walls,  each  housing  one  lottery  ticket 
machine.  Each  machine  can  dispense  up  to  three  different  types  of  lottery  tickets  and 
has  its  own  coin  slot  (quarters  only),  dollar  bill  slot  (ones  only),  and  selection  panel. 
The  selection  buttons  each  show  a  graphical  representation  of  the  type  of  lottery  ticket 
to  which  the  button  corresponds,  or,  an  "empty"  indicator. 

To  use  any  of  the  ticket  machines,  a  customer  enters  money  and  then  uses  the 
selection  panel  to  select  the  type  of  lottery  tickets  and  the  numbers  to  play.  The 
customer  may  make  multiple  selections  and,  for  each,  he/she  enters  the  ticket  type 
(daily,  weekly,  or  monthly)  and  five  numbers  (numbers  from  1  to  20  can  be  selected). 
After  all  selections,  the  customer  presses  a  "dispense"  button.  If  sufficient  money  has 
been  entered  (initially  all  tickets  are  $1).  the  selected  lottery  tickets  and  correct  change 
are  dispensed.  A  transaction  can  be  cancelled  at  any  time  prior  to  hitting  the 
"dispense"  button  and  the  money  is  returned.  If  a  customer's  selections  cannot  be 
honored  for  any  reason,  his/her  money  is  also  returned.  Each  lottery  ticket  dispensed 
contains  the  time  and  date,  the  machine  number,  and  the  five  numbers  selected. 

All  three  lottery  ticket  machines  share  a  common  control  system  that  keeps 
track  of  each  machine's  status  including  the  total  amount  of  money  taken  in,  the 
number  of  lottery  tickets  dispensed  (for  each  of  the  three  different  types),  and  the 
numbers  selected.  The  money  supply  and  money  input  is  shared  by  the  three 
machines  and  the  system  must  keep  track  of  the  number  of  coins  and  dollar  bills. 

An  operator  is  present  whenever  the  gazebo  is  open,  and  performs  system 
start'Up  and  shut-down  at  the  beginning  and  end  of  each  day,  respectively.  The 
operator  can  request  a  report  of  the  gazebo  status  as  well  as  the  status  of  any  of  the 
individual  lottery  ticket  machines.  The  operator  must  be  able  to  restock  the  ticket 
supply,  reprice  tickets,  and  replenish  and  collect  money.  At  the  end  of  each  day,  the 
operator  enters  the  winning  numbers  for  the  daily  lottery  and  requests  a  daily  lottery 
report  including  the  date,  winning  numbers,  number  of  winners,  and  the  amount  due 
each  winner.  Seventy-five  percent  of  the  money  is  distributed  evenly  among  the 
winners;  twenty-five  percent  goes  to  the  town.  In  a  similar  fashion,  once  a  week  the 
operator  requests  the  weekly  lottery  report,  and  once  a  month  he/she  requests  the 
monthly  lottery  report. 

Several  mechanical  malfunctions  can  occur  and  their  existence  is  indicated  by 
an  alarm  which  is  monitored  by  the  operator.  Alarm  conditions  indicate  the  ticket 
machine  involved  and  the  particular  condition.  Conditions  include  stuck  ticket 
dispenser,  stuck  coin  or  dollar  bill  slot,  machine  low  on  money  or  type  of  change, 
machine  out  of  money,  machine  out  of  tickets,  and  machine  or  door  open.  The 
operator  must  be  able  to  turn  the  alarm  indicators  off.  Stuck  ticket  dispensers  or  coins 
disable  the  particular  machine  until  it  is  senriced.  The  machine  out  of  money  condition 
disables  the  gazebo.  A  problem  analysis  report  is  generated  on  demand. 
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PROJECT  DESCRIPTION:  PAVIUON  RECYCLING  SYSTEM 


A  small  town  is  interested  in  developing  a  system  to  control  a  recycling  machine  for 
returnable  glass,  plastic,  and  metal  cans  or  bottles.  The  system  will  physically  be 
located  in  a  centrally  located  pavilion,  near  the  town  hall.  The  recycling  machine  can 
be  used  by  up  to  three  customers  at  the  same  time  and  each  customer  can  return  all 
three  types  of  items.  These  items  come  in  various  types  and  sizes.  The  machine 
must  check  which  type  of  item  was  turned  in  so  that  it  can  print  a  receipt.  A  receipt, 
which  can  be  taken  to  a  cashier,  will  be  printed  out.  The  receipt  must  contain  the  total 
value  of  the  items  turned  in  and  the  value  of  each  item  type  (glass,  plastic,  metal). 

The  machine  has  to  be  maintained,  so  information  kept  for  the  maintenance  operator 
must  include  the  total  quantity  of  each  item  type  that  has  been  turned  in  since  the  last 
time  the  totals  were  cleared.  This  information  should  be  able  to  be  printed  out.  In 
addition  to  these  totals,  the  maintenance  operator  should  be  able  to  change  the  values 
assigned  to  individual  item  types.  The  machine  has  numerous  mechanical  functions 
which  can  go  awry.  The  machine  has  an  alarm  which  indicates  that  an  item  is  stuck 
or  that  the  receipt  roll  is  out  of  paper. 

To  return  items  the  customer  first  presses  the  receipt  button  to  clear  all  totals.  The 
system  then  places  the  items  into  the  correct  item  type  slots.  With  each  item 
deposited  the  machine  increases  the  daily  totals  and  the  customer  totals  for  that  item 
type.  The  customer  presses  the  receipt  button  again  to  indicate  the  end  of  his/her 
transaction.  The  action  prints  the  receipt  and  updates  the  daily  totals. 

The  operator  needs  the  ability  to  turn  the  alarm  off.  print  the  daily  reports,  and  clear 
the  report  totals.  Not  only  can  the  value  of  the  items  be  changed,  but  because 
manufacturers  regularly  change  their  packaging,  the  operator  must  be  able  to  change 
the  allowable  sizes  for  each  item  type.  When  items  are  stuck  the  customer  is 
prevented  from  inserting  more  items  but  that  customers  totals  are  not  lost.  After  the 
stuck  item  is  cleared  from  the  machine,  the  customer  can  continue  to  insert  items 
which  are  added  to  his/her  previous  totals. 

Everything  associated  with  the  sorting  and  validating  of  the  glass,  plastic,  and  metal 
submitted  is  done  by  separate  hardware  located  within  the  recycling  machine.  This 
hardware  will  determine  the  type  and  size  of  items  submitted  and  provide  that 
information,  along  with  chute  number,  to  the  software  system. 

In  addition  to  the  daily  report,  weekly  and  monthly  reports  must  be  generated.  These 
will  be  requested  by  the  operator  at  the  end  of  each  day,  week,  and  month, 
respectively.  Each  of  these  reports  must  be  broken  down  by  type  of  recyclable  and 
chute  used,  and  must  also  report  grand  totals. 
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Software  Prelect  Managomont  Plan 
Small  Projact 

Week.cia88  CLld  Pflscription 

1  a  Requirements  statement  distributed 

1b  CI-1  Requirements  document:  abstract  of  project  and  detailed 

list  of  requirements 

2b  CI-2  Analysis  decisions  completed,  documents  delivered:  CD, 

DFO.  and  data  dictionary 

3b  Ci-3  Design  documents  delivered:  system  architecture  - 

structure  diart  and  external  descriptions  of  modules  and 
interfaces 

4b  CI-4  Test  plan  delivered:  classes  of  tests  for  each  requirement 

Presentation  of  design  review 

Modify  design  and  check  coding  standards 

Begin  coding  system  and  design  of  test  cases 

5b  Cl*5  Test  cases  delivered:  specific  tests,  their  input  and 

expected  output  and  thdr  relation  to  requirements 

Code  reviews  and  unit  tests  and  corrections 
System  testing  and  corrections  to  program 

6b  CI-6  Documented  source  code 

CI-7  Executable  code 

7a  Cl’8  Certified  Acceptance  Test:  documentation  of  test  cases 

and  their  relation  to  the  test  plan  and  documentation  of 
the  consistency  of  the  source  code  structure  with  the 
architectural  design;  also  include  package  of  CM  through 
CI-5 

Presentation  of  system  to  customer 

NOTE:  All  preeentation/revlew  Items  are  distributed  to  designated 

reviewers  24  hours  prior  to  the  preeentation/revlew. 
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DATE:  LOCATION:  START  TRIE:  END  TIME: 

PRESENT:  ABSENT: 


_ AQENPA _ 

ITEM  PERSON  RESPONSIBLE 

1. 


RESOLUTION: 

2. 


RESOLUTION: 


3. 


RESOLUTION: 


4. 


RESOLUTION: 
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SUMMARY  (Ntw  IMUM,  dMIeuMM,  Me): 


TASKLIST 

lASE _  PUB.  PATE  PH»QN  RESPOfiMLE 
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Context  diagrams 
Data  flow  diagrams 
Levattng 
Baianci^ 

INSTRUCTIONAL  OBJECTIVEfS^: 

1.  Identify  external  entities,  system  inputs,  and  system  outputs  from  a  problem 
specification  in  the  form  of  a  context  diagram. 

2.  Develop  the  first  level  of  a  data  flow  diagram  from  a  context  diagram. 

3.  Verify  the  balancing  of  a  data  flow  diagram  with  a  context  diagram. 

ASSOCIATED  LECTURg  NUMBER: 

Lecture  004 

SET  UP.  WARM-UP: 

During  the  associated  lecture  session  the  students  were  introduced  to  the  concepts  of 
context  diagrams,  data  flow  diagrams,  leveling,  and  balancing.  During  this  class 
presentation  the  students,  as  a  group,  examined  several  examples  of  context  diagrams 
and  data  flow  diagrams  as  well  as  developing  ones  from  a  problem  specification.  A 
problem  of  a  similar  level  is  presented  here  for  the  small  project  teams  to  attempt,  as  a 
group,  to  develop  a  context  diagram  and  first-level  data  flow  diagram. 

ERQfiEDURE: 

1 .  HANDOUT  •  A  narrative  description  of  a  client  request 

The  students,  separated  into  th^r  project  teams,  are  handed  a  brief  description  of 
a  problem  specification  and  are  given  10  minutes  to  develop  a  context  diagram. 

2.  The  dass  is  reconvened  as  one  group.  The  instructor  draws  the  drde 
representing  system  in  the  context  diagram  on  the  board  and  solicits  inputs, 
outputs,  and  external  entities  from  the  various  teams.  This  is  used  to  discuss  the 
scope  of  the  problem  (e.g.,  what  is  Included  and  what  is  exduded  from  the 
system)  and  to  darify  the  problem  description.  The  result  is  a  context  diagram  to 
be  used  as  input  to  the  next  step  in  this  lab. 

3.  Steps  1  and  2  are  repeated  to  develop  a  first  level  data  flow  diagram. 


ASSOCIATED  HANDOUTS: 

Narrative  description  of  a  dient  request 
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EXAMPLE  OF  CUENT  REQUEST  -  MATCH  MAKING  SERVICE 


I  run  a  match-making  service  that  I  want  to  automate.  Here's  how  it  works.  I  guarantee 
people  who  subscribe  to  my  service  that  I  will  provide  them  with  the  names  of  ttiree 
compatible  persons  of  the  opposite  sex  whenever  they  request  with  the  following  two 
conditions; 

(1)  they  can't  request  names  more  than  once  a  month;  and 

(2)  they  cant  expect  all  three  names  provided  to  be  new  (since  their  previous 
requests)  unless  they  have  contacted  and  talked  to  those  provided  on 
previous  lists.  (I.e.  any  name  on  a  previous  list  will  continue  to  appear  on 
new  lists  unless  they  have  contetcted  and  talked  to  that  person  and  reported 
it  back  to  me). 

I  build  a  profile  for  each  subscriber.  The  profile  includes  such  things  as  personality  traits, 
interests,  intellectual  level,  education,  age.  values,  etc.  The  profile  is  based  on 
information  obtained  from  three  sources:  a  detailed  questionnaire  completed  by  the 
subscriber;  a  personal  interview  with  the  subscriber;  and  a  questionnaire  completed  by 
each  of  three  references  whose  names  are  provided  by  the  subscriber. 

People  who  want  to  subscribe  to  the  match-making  service  are  not  automatically 
accepted.  A  review  of  applicant  is  conducted  based  on  the  questionnaire,  references, 
and  medical  history.  Based  on  the  review,  applicants  are  notified  of  their  acceptance  or 
rejection. 


2 


Lab  002 


EXAMPLE  OF  CUENT  REQUEST  •  SMALL  COLLEGE  BOOK  ORDERING 

The  following  describes  how  the  bookstore  at  a  small  private  college  manages  the 
ordering  of  textbooks. 

The  bookstore  maintauns  an  inventory  card  for  each  course  in  the  college  catalog. 
Each  inventory  card  contains  the  title,  author,  and  publisher  of  the  textbook 
currently  used.  It  also  contains  the  number  of  the  textbooks  that  are  already  in 
stock. 

Midway  through  the  spring  semester,  each  academic  department  provides  the 
bookstore  with  textbook  information  for  each  course  they  will  be  offering  in  the  next 
academic  year.  The  information  provkied  is  title,  author,  and  publisher  of  textbook 
to  be  used,  and  the  expected  course  enrollment. 

The  bookstore  then  creates  a  Books  Needed  File  containing  the  title,  author, 
publisher,  and  number  needed  (expected  enrollment  minus  the  number  in  stock) 
for  each  book  to  be  used  in  the  next  academic  year. 

During  the  last  week  of  the  spring  semester  the  bookstore  will  buy  books  from 
students  if  the  Books-Needed-File  indicates  a  need.  Of  course,  each  time  a  used 
book  is  purchased,  appropriate  updates  are  made  in  the  bookstore's  records. 

Over  the  summer  the  bookstore  prepares  an  Order-List  containing  the  title,  author, 
publisher,  and  number  to  be  ordered  for  each  book  that  is  still  needed.  The  Order 
List  is  then  used  to  create  an  individual  Book  Order  Form  for  each  publisher. 
These  Book  Order  Forms  are  sent  to  ttie  publishers. 


3 


Lab  002 


EXAMPLE  OF  CUENT  REQUEST  -  STUDENT  GOVERNMENT  ELECTION 

As  the  advisor  to  the  Student  Government  ^sodation  (SGA),  I  would  like  an  automated 
election  system  developed.  The  system  could  then  be  used  for  SGA  elections,  various 
referenda,  and  other  types  of  campus  elections  (for  example,  balloting  for  homecoming 
king  and  queen)  that  are  conducted  by  student  organizations. 

I  would  like  to  be  able  to  use  the  system  to  create  the  ballot,  to  conduct  the  voting,  and 
to  report  results.  Typical  SGA  elections  consist  of  several  types  of  votes.  First,  there  are 
several  offices  for  which  all  eligible  voters  can  vote  for  one  exactly  candidate  (e.g.,  for 
offices  such  as  President.  Vice-President.  Secretary,  etc).  Second,  senators  are  elected 
to  represent  a  particular  school  or  college  and  only  students  majoring  in  that  school  or 
college  are  eligible  to  vote.  For  example,  the  College  of  Arts  and  Sciences  may  have  7 
senate  seats  and  12  candidates.  In  that  case,  students  majoring  in  a  department  within 
Arts  and  Sciences  would  be  able  to  vote  for  up  7  candidates  from  a  list  ^12.  Similarly 
College  of  Business  majors  elect  senators  to  represent  business,  and  so  on  for  each 
school  or  college.  Incidentally,  there  are  also  a  number  of  "at  large”  senate  seats  for 
which  all  students  vote.  Third,  there  may  be  issues  placed  on  the  ballot. 

I  envision  a  system  in  which  we  would  strategically  place  PC's  to  sen/e  as  "voting  booths” 
at  several  campus  locations  and  students  would  use  these  to  cast  their  votes.  The  ballot 
would  have  previously  been  created  and  placed  in  these  machines. 
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TWPICtS)  f  OH  LAH: 

Requirements  list  for  small  project 

Context  diagrams 

Data  flow  diagrams 

Leveling 

Balancing 


QBJECTIVE(S): 

1 .  Clarify  requirements  for  small  project. 

2.  Identify  external  entities,  system  inputs,  and  system  outputs  from  a  problem 
specification  for  the  team's  small  project  in  the  form  of  a  context  diagram. 

3.  Develop  the  data  flow  diagram  flows  for  the  team's  small  project. 

4.  Verify  the  balancing  of  the  data  flow  diagrams  and  context  diagram. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  005 

SET  UP.  WARM-UP: 

During  an  earlier  lecture  session,  the  students  were  introduced  to  the  concepts  of  context 
diagrams,  data  flow  diagrams,  leveling,  and  balancing.  The  students,  as  a  group, 
considered  several  examples  of  context  diagrams  and  data  flow  diagrams  as  well  as 
developing  ones  from  a  problem  specification.  The  students  also  worked  individually  on 
a  problem  of  a  level  similar  to  their  first  team  project.  The  possible  answer  was 
discussed  during  class.  The  teams,  on  their  own,  b^in  developing  these  same  diagrams 
for  their  small  project. 

EBQCEDU.RE: 

1 .  The  students  meet  in  their  Individual  teams  to  discuss,  with  their  customer,  the 
abstract  and  requirements  list  which  they  have  previously  submitted  to  their 
customer.  This  interaction  is  intended  as  a  preliminary  review  to  make  sure  that 
the  requirements  list  is  an  adequate  first  draft  (i.e.  to  assure  they  are  on  the  right 
track  and,  if  not,  to  redirect  them).  If  there  are  multiple  small  project  teams  then 
other  faculty  can  act  as  customers  for  the  projects. 

2.  Based  on  these  documents  and  their  discussion  with  their  customer,  the  students 
are  given  the  rest  of  the  lab  period  to  begin  work  on  their  context  diagram  and 
data  flow  diagrams  for  the  small  project.  The  customer  does  not  meet  with  the 
student  team  during  this  time  but  is  readily  available  should  questions  arise. 


ASSOCIATED  HANDOUTS: 
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LAB.  NUMBER:  004 


TQPIC(S)  FOR  LAB: 

Structure  charts 
Coupling 
Cohesion 
Fan-in,  Fan-out 

iNSTRUCTiONAL  OBJECTIVEfSh 

1 .  Clarify  understanding  of  notation  and  content  of  structure  charts 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  006 

SET  UP.  WARM-UP: 

During  an  earlier  lecture  session,  the  students  were  introduced  to  the  structure  charts  as 
a  design  representation,  including  the  notation  used  and  the  information  conveyed  in 
structure  charts.  Also  discussed  were  coupling,  cohesion,  fan-in,  and  fan-out  as  design 
criteria.  As  a  followup,  we're  going  to  examine  some  structure  charts  to  verify  your 
understanding. 

PROCEDURE: 

1 .  Provide  a  well-designed  structure  chart  and  briefly  explain  the  system  depicted. 
Examples  are  plentiful,  including  the  following: 

a.  Mynatt,  pp.  161  -  Subscription  system 

b.  Mynatt,  pp.  165  -  Concordance  system 

c.  Schach,  pp.  295  -  Count  words  in  a  file 

d.  Conger,  pp.  299  -  Master  file  update 

e.  Kendall,  pp.  348-353  -  Pay  invoice  system 

f.  Eliason,  pp.  466-467  -  Enter  oistomer  payments 

2.  Ask  a  series  of  specific  questions  aimed  at  clarifying  the  notation  and  terminology 
of  structure  ^arts.  These  should  cover  hierarchical  Issues,  notation  for  data  and 
control  couples,  fan-in  and  fan-out  counts,  and  naming  of  components. 

3.  Ask  a  series  of  discussion  questions  to  illustrate  how  one  can  examine  a  design 
through  the  structure  chart.  Include  discussion  of  interfaces  (coupling  and 
cohesion). 

ASSOCIATED  HANDOUTS: 

Structure  chart  example 
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LAB  NUMBER:  005 


TOPICfS)  FOR  LAB: 

Preliminary  design  (structure  chart,  external  module  description) 

INSTRUCTIONAL  QBJECTIVE(S): 

1.  Begin  development  of  CI-3.  a  structure  chart  and  external  module 
descriptions,  for  the  small  team  project. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  007 

SET  UP.  WARM-UP: 

Recall  that  we  described  requirements  analysis  and  specification  as  extraction 
processes  and  as  iterative  processes.  As  you  proceed  in  your  projects  it  will 
continue  to  be  important  to  interact  with  your  customer,  and  refine  and  change  the 
requirements  and  associated  documentation  as  changes  occur.  We  have  looked 
over  your  CD,  DD,  and  DFDs  (CI-2)  recently  submitted  and  noted  problems  that 
need  to  be  addressed  before  b^inning  your  designs.  The  requirements  have  to 
be  accurate  before  you  build  your  design  on  them. 

Then  we  want  you  to  begin  the  designs,  as  illustrated  in  the  lecture,  for  your  small 
project.  Specifically  you  are  to  develop  a  structure  chart  and  external  descriptions 
of  the  components. 

PROCEDURE: 

1 .  Feedback  of  the  first-draft  CD,  DD,  and  DFDs  are  provided  to  each  team 
(separately)  based  on  a  preliminary  review,  by  the  instructor,  of  the 
functionality  and  the  notation.  This  interaction  also  provides  a  further 
opportunity  for  requirements  to  be  refined  and  understood.  It  is  made  clear 
that  any  problems  identified  are  to  be  addressed  and  incorporated  into  all 
documentation. 

2.  Teams  are  given  the  remainder  of  the  period  to  begin  development  of  their 
structure  chart  and  external  module  descriptions  (CI-3).  The 
customer/instructors  are  available  for  the  remainder  of  the  lab  period. 

ASSOCIATED  HANDOUTS: 
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TQPICfS)  FQR.IAB: 

Additional  feedback  on  CI-2 
Preparation  for  small  project  teams*  design  review  presentations 

iriSTflUCTiQNAL.QBJECTIY£(S): 

1 .  Understand  suggestions  to  improve  and/or  correct  teams'  first  drafts  of  CD, 
DD,  and  DFDs  submitted  previously. 

2.  Begin  preparing  teams  for  design  review  presentations. 

ASSOCIATED  LECTURE  NUMBER: 

Lectures  007  and  008 

SET  UP.  WARM-UP: 

As  you  further  refine  the  project  requirements,  interaction  with  your  customer  and 
one  another  continues  to  be  critical.  As  changes  and  refinements  occur,  it  is  also 
critical  to  modify  all  CIs  to  reflect  the  current  system.  We  have  done  a  more 
thorough  review  of  your  CD,  DD,  and  DFDs  and  want  to  discuss  our  findings  so 
that  you  can  incorporate  our  suggestions  into  your  model. 

In  addition,  we  want  to  prepare  you  for  the  upcoming  design  review  presentations. 
As  a  team,  you  have  spent  a  g(^  deal  of  time  extracting  and  understanding  your 
customer's  needs  and  attempting  to  specify  them  clearly  and  completely.  At  this 
point  it  b  in  the  best  interests  of  both  you  and  your  customer  to  have  that  work 
more  formally  reviewed  for  the  purpose  of  improving  it  and  to  assure  that  it  is 
complete  and  correct.  That  is  the  intent  of  the  design  review.  In  preparation,  we 
are  also  going  to  review  some  general  procedures  for  reviews  and  point  out  some 
common  pitfalls. 


ERQCEPURE: 

1 .  Detailed  feedback  on  the  first-draft  CD,  DD,  and  DFDs  are  provided  to  each 
team  (separately).  Careful  attention  has  been  given  to  both  notation  and 
functionality.  This  interaction  also  provides  a  further  opportunity  for 
requirements  to  be  refined  and  understood.  It  is  made  ctear  that  the 
corrections  are  to  be  incorporated  into  all  documentation. 

2.  The  predominant  method  of  design  evaluation  is  the  design  review. 
Typically  design  reviews  are  conducted  at  several  points  in  the  design 
process.  At  each  review,  the  basic  questions  to  keep  in  mind  are: 

(1 )  Does  the  design  fulfill  the  requirements? 

(2)  Does  the  design  meet  established  design  standards  (quality, 
maintainability,  cohesion,  coupling,  reuse,  testability, ...) 
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To  show  that  the  design  fuifiils  the  requirements,  the  reviewer  can  go 

through  the  requirements  list,  one-by-one,  and  assure  that  the  design  meets 

the  requirement.  How  effe^ive  this  is  depends  on  the  quality  of  the 

requirements  list. 

3.  Discuss  the  following  regarding  the  formal  design  review  presentations. 

a.  The  purpose  of  the  review  is  to  improve  the  product.  All  participants 
(develo^rs.  customers,  and  other  reviewers)  have  a  common  goal: 
to  iden%  problems  tfiat  need  to  be  addressed  and  to  come  out  with 
clear  and  complete  requirements  that,  if  met,  will  satisfy  the 
customer.  This  is  a  oualltv  assurance  activitv. 

b.  A  common  tendency  of  the  development  team  is  to  defend  their  work 
and,  in  so  doing,  to  resist  change.  It  is  understandable  why  this 
occurs  but  clearly  it  is  contrary  to  the  purpose  of  the  review.  It  is 
much  easier  and  cost  effective  to  make  changes  now  than  later. 

c.  Another  manifestation  of  this  problem  is  the  "that  wasn't  in  the 
specs"  response.  Its  unrealistic  to  expect  the  specs  to  be  complete. 
As  the  maintenance  lecture  and  readings  demonstrated,  most 
defects  can  be  traced  to  requirements  problems.  Your  job  is  to 
extract  requirements  and  then  improve  them  if  necessary. 

d.  Reviews  are  to  identify  problems  but  not  to  solve  them.  Resist  the 
urge  to  come  up  with  solutions  (to  hack)  during  the  review,  or  to  let 
others  come  up  with  solutions.  Note  the  issue  and  assure  the 
customer  that  it  will  be  addressed  if  possible. 

e.  The  customer  is  the  person  whose  needs  must  be  met  and  the 
customer  is  the  person  who  is  going  to  pay  you.  You  cani  insult  the 
customer  by  implying  that  you  understand  his/her  needs  better  than 
he/she  does.  (Even  if  you  do,  and  you  probably  donl.) 

f.  Sometimes  the  best  answer  is  "I  don't  know”  or  "we  didn't  consider 
that".  It's  unusual  ost  to  have  some  requirements  that  were 
overlooked  or  misunderstood.  Assuring  the  customer  that  the  issue 
will  be  addressed  (and  subsequently  addressing  it)  is  sufficient. 

Bluffing,  or  conning,  to  "cover  yourselT  is  dangerous.  You  are 
unlikely  to  fool  everyone  and  you  risk  damaging  your  credibility.  One 
of  the  things  happening  at  these  reviews,  particularly  early  ones,  is 
that  you  are  building  a  rapport  with  the  customer;  you  are 
establishing  credibility. 

g.  This  is  a  team  effort.  A  team  working  on  a  project  is  different  from 
a  group  where  each  irKfividual  is  working  on  different  things.  The 
customer  should  see  a  team  working  on  "our  project"  rather  than  a 
group  of  individuals,  each  working  on  "his/her”  part.  All  teams 
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members  should  be  knowledgeable  about  the  entire  project,  but  each 
will  have  more  detailed  knowledge  in  particular  areas.  Cooperating 
in  responses,  deferring  a  question  to  the  appropriate  person,  is 
appropriate.  Demonstrate  that  you  are  a  team. 

f.  Plan  the  presentation  ahead  of  time.  Doni  wing  it.  Plan  who  will  do 
what,  and  when.  Then  make  a  dry  run  of  the  entire  presentation 
ahead  of  time.  This  is  necessary  even  if  each  person  has  his/her 
part  well  prepared.  To  do  otherwise  is  analogous  to  doing  unit 
(module)  testing  and  not  doing  integration  testing. 

This  will  eliminate  timing  problems  and  smoo^  transitions  in 
the  presentation.  A  common  problem  is  abrupt  transitions. 

4.  HANDOUT  -  Preliminary  design  review  form 

Distribute  and  discuss  preliminary  design  review  form.  Each  student  will 
utilize  this  form  as  a  reviewer  (in  reviewing  the  other  team  presentations.) 

5.  HANDOUT  -  Suggestions  for  giving  and  oral  presentation 

Distribute  and  discuss  suggestions  for  giving  an  oral  presentation.  These 
suggestions  are  for  an  oral  presentation  in  general  but  are  directly 
applicable  to  the  team  presentations  that  will  occur  throughout  the  coume. 

6.  HANDOUT  •  Oral  presentation  evaluation  form 

Discuss  the  evaluation  form.  This  will  be  used  by  reviewers  to  provide 
feedback  on  all  presentations  in  the  course. 

7.  Remind  students  that  material  to  be  reviewed  must  be  provided  to 
reviewers  in  advance.  Make  arrangements  for  the  materials  to  be  provided 
to  the  instructors  for  duplication  and  then  made  available  to  the  reviewers. 

ASSOCIATED  HANDOUTS: 

Preliminary  design  review  sheet. 

Suggestions  for  giving  and  oral  presentation 

Oral  presentation  evaluation  form 
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Preliminary  Design  Review  Form 


Project  Name  _ 

Reviewer  Name  _ 

I.  High  Level  Issues 

A.  Requirements:  any  requirements  missed,  requirements  over-worked? 


B.  Design  ;  suggestions  for  improvement  of  architecture  or  procedures;  other 
strategies 


il.  Design  Oeliverabie  Detaifs 

A.  Test  Plan:  items  over-tested  or  under-tested,  suggested  tests 


B.  DFD:  good  use  of  notation,  dear  model,  suggested  improvements 


C.  Comments  on  other  deliverables 
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Suggestions  For  Giving  An  Oral  Presentation 

1 .  In  preparation,  concentrate  on  "why"  rather  than  "how"  questions.  Why  am  I 
giving  this  talk?  Why  is  this  audience  interested  in  this  topic?  Ask  yourself: 

A.  What  is  my  purpose?  (For  example,  am  I  reporting  on  a  topic,  am  I 
arguing  a  case,  am  I  trying  to  change  their  opinion,  etc.?) 

(1)  Why  am  I  talking  to  this  audience  about  this  topic? 

(2)  What  do  I  want  them  to  know,  think,  do.  or  feel  as  a  result  of  my 
talk?  Do  I  want  to  change  their  opinion  on  the  subject? 

(3)  What  must  I  do  in  my  presentation  to  achieve  this? 


B.  Who  will  be  listening  to  me?  (I.e.  who  is  the  audience?) 

(1)  How  much  do  they  know  about  my  topic?  (Don't  always  assume 
that  they're  already  familia'  with  the  topic.) 

(2)  What  is  their  attitude  about  my  topic? 


2.  Prepare  and  then  rehearse  the  presentation.  Don't  "wing  it".  Lack  of 
preparation  is  usually  obvious  to  the  audience.  Get  a  friend  to  watch  you 
rehearse  the  presentation  or  rehearse  in  front  of  a  mirror. 


3.  Check  out  the  room  ahead  of  time.  Make  sure  you  know  how  to  operate  any 
equipment  you'll  be  using  and  make  sure  it’s  working  properly. 


4.  You'll  usually  have  a  specific  amount  of  time  allotted  for  the  presentation.  Use 
it  wisely.  Organization  and  format  are  critical,  especially  when  the  allotted  time 
is  short.  Be  sure,  through  rehearsing,  that  your  presentation  fits  the  time 
allotted. 


5.  Consider  this  outline  for  your  presentation. 

A.  INTRODUCTION  •  Give  the  ^ie  of  the  presentation,  your  name,  and  the 
names  of  anyone  else  involved.  (For  example  if  you  are  presenting  the 
work  of  a  team,  identify  the  team  members,  if  you  are  presenting  a 
review  of  an  article,  identify  the  author  and  source  of  the  article.) 

B.  OVERVIEW 

(1)  Purpose  and  scope  -  Doni  assume  the  audience  is  already 
familiar  with  the  topic.  Give  a  brief  description  (i.e.  an  abstract). 
Jumping  immediately  into  details  will  quickly  lose  the  audience. 
This  is  the  time  to  give  your  audience  a  reason  to  listen  to  you. 

(2)  Outline  of  presentation. 
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C.  BODY  OF  PRESENTATION  -  Have  a  specific  but  limited  number  of 
points  to  cover;  doni  try  to  do  too  much.  Make  a  smooth,  logical 
transition  between  points  as  well  as  between  the  introduction  and 
overview,  the  overview  and  the  body,  and  the  body  and  the  conclusion. 

D.  CONCLUSION  -  Summarize  key  points,  findings,  or  recommendations. 

E.  QUESTIONS  •  There  may  be  a  planned  question  and  answer  period  to 
follow  the  presentation.  If  not,  aJIow  a  few  minutes  for  questions.  Don't 
be  intimidated  or  defensive;  usually  the  questioner  is  genuinely  interested 
and  may  even  be  helping  emphasize  or  clarify  a  point.  Answer  as  best 
you  can  and  don't  be  afraid  to  say  "I  don't  know". 

6.  Use  the  speaking  medium  to  its  best  advantage.  Remember  you  are  giving  a 
talk,  not  a  written  report.  Use  the  strengths  of  oral  speech.  Give  the  big 
picture;  explain  rationales;  motivate  the  audience.  Oral  communication  is  a 
much  more  natural,  personal,  human  activity  than  Is  written  communication. 

Talk  to  and  look  at  your  audience. 

7.  Avoid  technical  jargon  unless  you're  sure  it  is  familiar  to  the  audience.  Use 
simple  straightforward  sentences.  Explain  dearly  the  real  meaning  of  any 
statistics,  numbers,  charts,  or  graphs  that  you  use. 


8.  Include  your  own  opinions,  observations,  or  perceptions.  Personalize  the  topic 
to  your  own  (and/or  the  audience's)  common  experiences. 


9.  If  appropriate  use  visual  aids  to  enhance  the  presentation  but  remember  that 
they  are  aids  to  your  talk  and  should  not  simply  display  the  same  words  you're 
speaking.  They  can  be  overhead  transparendes,  chalk/chalkboard,  handouts, 
slides,  computer  demonstration,  or  combinations  of  these.  Visual  aids  can 
support,  enhance,  darify  subject  matter  and  to  focus  attention  on  major  points. 

They  must  be  visible  to  the  audience;  they're  not  effective  if  your  audience  cant 
see  them.  This  is  a  common  mistake  in  using  a  computer  demonstration  in 
which  the  screen  can  be  seen  by  only  part  of  the  audience  or  when  the  print  on 
overhead  transparendes  is  too  small  or  too  light.  Make  sure  your  visual  aids 
are  legible  and  large  enough  to  be  seen. 

Make  the  message  of  each  visual  aid  dear.  Beware  of  induding  too  much. 
Keep  them  simple. 

Don't  read  the  visual  aids;  use  them  to  focus  attention  on  key  points.  One  of 
the  quickest  ways  to  lose  your  audience  is  to  read  to  them  instead  of  speaking 
to  them. 
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10.  Most  presenters  are  nervous  but  it  doesnl  have  to  hurt  the  effectiveness  of  the 
presentation.  The  audience  will  tolerate  nervousness  and,  in  fact,  will  tend  to 
"pull  for  you".  They  woni  tolerate  your  disinterest  or  lack  d  preparation.  Give 
the  audience  the  sense  that  you’ve  got  scmething  to  say;  that  you  want  to  be 
there.  Some  suggestions  to  help  deal  with  your  nervousness: 

A.  Prepare. 

B.  Maintain  eye  contact.  Look  at  and  speak  to  the  audience. 

C.  Move  around  as  you  speak;  use  some  expres^n.  Come  out  from 
behind  the  podium.  Doni  lean  on  the  podium  or  sit  on  the  desk.  Show 
that  you're  interested. 

D.  Avoid  nervous  or  annoying  mannerisms  and  expressions.  Rehearsing 
the  presentation  will  help  reveal  these. 

E.  If  you  use  written  notes  then  fxjt  them  on  index  cards.  They're  less 
obvious  and  avoid  the  effect  of  "nervous  hands"  shaking  your  notes  and 
distracting  the  audience. 


1 1 .  Dress  appropriately.  If  you're  not  sure  what  is  appropriate  then  find  out  ahead 
of  time.  It's  possible  to  be  over-dressed  and  it's  possible  to  be  under-dressed. 


7 


Lab  006 


ORAL  PRESENTATION  EVALUATION  FORM 


PRESENTER _  EVALUATOR _ 

Use  the  scale  below  to  rate  the  presentation  on  Organization,  Delivery,  Content,  and  Overall 
Effectiveness.  The  following  qualities  should  be  present  for  an  ABOVE  AVG  to  EXC  rating. 

ORGANIZATION 

*  Obviously  well  prepared,  organized 

*  Intro  includes  (1)  name  of  presemer  &  others  involved  (project  team,  committee,  advisor, 
ete);  (2)  purpose;  (3)  brief  overview 

*  Bo^  of  talk  covers  main  ideas;  smooth  transitions  between  points 

*  Concludes  with  definite  ending;  summarizes  main  pcrints 

*  Uses  time  weN,  stays  within  allotted  time  frame  (excluding  questions) 

DEUVERY 

*  Obvious  knowiedge/understanding  of  subject 

*  Talks  (not  reads)  to  audience;  k)^  at  audience 

*  Poised;  able  to  control  nervousness;  no  distracting  mannerisms;  good  posture;  natural 
movement;  appropriately  dressed 

*  Talks  clearly,  easily  understood,  good  grammar  &  pronunciation 

CONTENT 

*  All  requirements  specified  in  particular  assignment  met 

*  Essence  of  talk  clearly  conveyed  to,  understood  by  audience 

*  Supporting  materials  and  visual  aids,  if  used,  enhanced  presentation;  were  easy  to 
read/understand  by  all;  were  effective 

*  Questions  handled  well 


Mark  an  X  to  indicate  your  rating.  The  scale  ranges  from  unsatisfactory  (UNS)  on  the  left  to 
excellent  (EXC)  on  the  right. 

_ QBSAMgATiQM-BATINfl _  DELIVERY  RATING _ 

BELOW  ABOVE  BELOW  ABOVE 


UNS  AVG  AVG  AVG  EXC 


CONTENT  RATING 


UNS  AVG  AVG  AVG  EXC 

_ OVERALL  RATING 


BELOW  ABOVE 

UNS  AVG  AVG  AVG  EXC 


BELOW  ABOVE 
UNS  AVG  AVG  AVG  EXC 


Please  use  other  side  for  additional  comments. 
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kl*Jki 


Test  plans 


I  k  i  i  i.*i  k  f«’ 


1 .  Develop  CI-4  (classes  of  tests)  for  small 


1 ' '' 


Lecture  009 


P.  WARM-UP: 

In  the  testing  lecture  we  distributed  and  discussed  a  preliminary  test  plan  for  the 
KoFF  Video  Rental  System.  A  key  feature  was  the  traceabllty  between  tests  and 
requirements.  We  want  you  to  develop  a  similar  test  plan  for  your  small  projects; 
in  particular,  the  equivalent  to  section  4.0  (Figure  3.5-1 )  of  the  Koff  preliminary  test 
plan.  The  test  plan  you  develop  will  form  the  basis  for  acceptance  testing  of  the 
system. 


EC[UB£: 


Refer  back  to  the  Koff  Preliminary  Test  Plan.  Spedficaliy  review; 

a.  Section  3.1  (Requirements  Traceability)  and  Rgure 
(Test/Requirement  Traceability  Matrix); 

b.  Section  4.0,  Rgure  3.5-1  (Tests  to  be  performed). 


3.2-1 


In  this  example,  first  discuss  foe  development  of  categories  of  tests.  Then 
discuss  the  development  of  items  to  be  tested  within  each  category, 
followed  by  the  ordering  of  the  tests  and  prerequisites  for  each  test. 

Teams  are  given  the  remainder  of  the  period  to  meet  and  begin 
development  of  a  test  plan  (Ci-4)  for  the  small  project.  Their  customer  and 
the  instructors  are  available  for  the  remainder  of  the  lab  period. 


Preliminary  test  plan  for  KoFF  system  (distributed  in  associated  lecture) 
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LAB  NUMBSH:  006 


TOPICfS)  FOR  LAB: 

Design  review  team  presentations  for  smali  projects 

INSTRUCTIONAL  QBJECTIYEIS): 

1 .  Present  requirements,  design,  and  test  plans  for  review. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  010 

SET  UP.  WARM-UP: 

Earlier  we  GNscussed  the  purpose  and  general  procedures  of  formal  reviews. 
Today  we  are  all  going  to  partidpate,  each  in  multiple  roles,  in  preliminary  design 
reviews  for  your  smali  projects.  Each  of  you  will  partidpate  as  a  member  of  a 
team  whose  work  is  being  reviewed  and  as  a  reviewer  for  the  other  teams. 
Remember  that  the  purpose  of  the  review  is  to  improve  the  quaRty  of  the  software 
system  under  development. 

PROCEDURE: 

1 .  a.  Remind  teams  that  during  their  review  they  should  note  any  issues 

which  arise  that  require  attention.  Each  item  on  this  "issues  list" 
must  be  addressed  and  appropriate  modifications  made  where 
needed.  The  issues  list  thus  serves  as  action  item  checklist  for  the 
team  as  they  addresses  the  issues. 

b.  The  instrudor  should  maintain  his/her  own  issues  list  as  a  means  of 
establishing  a  fbllow-up  procedure  to  assure  that  the  items  are 
addressed. 

2.  Determine  the  order  of  the  team  presentations  and  begin  the  reviews. 

Instructors  should  maintain  their  role  as  customer  as  much  as  possible, 
reverting  to  role  of  instructor  only  when  necessary  for  such  things  as 
maintaining  the  schedule,  reminding  participants  of  the  purpose  and/or 
ground  mles,  and  maintaining  order.  Critiques  should  be  saved  until  the 
next  lecture  or  lab. 

ASSOCIATED.  HANDOUTS; 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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LAB  NUMBER:  009 


TOPICfS)  FOR  LAB: 

Feedback  on  design  review  presentations. 

INSTRUCTIONAL  OBJECTIVEfSk 

1 .  Provide  timely  feedback  on  recent  design  review  presentations. 

2.  Provide  timely  feedback  on  ail  configuration  items  for  small  projects 
submitted  to  this  point. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  01 1 

SET  UP.  WARM-UP: 

You  recently  experienced  your  first  design  review  presentation  with  your  customer 

and  other  reviewers.  We  want  to  provide  you  with  our  reactions  to  the 

presentations. 

PROCEDURE: 

1 .  With  all  teams  present,  provide  general  information  pertaining  to  customer 
reviews  in  general.  Defer  specific  comments  on  their  presentations  for 
individual  meetings  with  each  team.  It  is  helpful  to  review  the  guidelines 
presented  in  Lab  006  and  relate  them  to  specifically  to  their  reviews. 

2.  Meet  separately  with  each  team  to  provide  specific  feedback  on  the  items 
reviewed  (requirements  list,  CD,  DD,  DFDs,  structure  chart  and  interface 
descriptions,  and  test  plan).  Specifically  ask  about  their  "issues  list"  which 
should  have  been  compiled  during  the  review.  (Use  your  own  issues  list  as 
a  check.)  Ask  how  each  item  was  addressed  and  the  disposition  of  each. 

This  meeting  is  critical  to  estsdjiish  baseline  requirements  and  design. 
Teams  are  about  to  begin  implementation  and  agreement  must  be  reached 
on  what  is  to  be  implemented;  in  a  sense  the  requirements  and  design  are 
being  frozen  (after  the  necessary  changes  based  on  the  review  are  made). 
An  early  deadline  needs  to  be  placed  on  teams  for  making  the  necessary 
revisions  and  baselining  the  configuration  items. 

ASSOCIATED  HANDOUTS: 
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LAB  NUMBER:  010 


TOPIC(SI£QR  LAB: 

Feedback  on  CI-5,  test  plans  and  test  cases. 

Small  project  team  preparation  for  team  acceptance  test  presentations. 

INSTRUQTJQNAL  OBJECTIYEIS): 

1 .  Provide  timely  feedback  on  Ci-5. 

2.  Prepare  teams  for  acceptance  review  presentations  of  small  projects. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  012 

SET  UP.  WARM-UP: 

Soon  your  team  will  be  meeting  with  your  customer  to  conduct  acceptance  testing. 
Today  we  want  to  review  your  test  plans  and  test  cases  in  preparation  for  an 
acce^ance  test  with  the  customer. 

PROCEDURE: 

1 .  Distribute  copies  of  each  team's  Ci-5  to  the  class.  Discuss  each  of  these. 
Pay  particular  attention  to  whether  ail  requirements  are  completely  tested. 

2.  HANDOUT  -  Acceptance  test  review 

Distribute  and  discuss  acceptance  review  checksheets. 

Discuss  how  their  test  review  presentations  will  differ  from  a  normal 
acceptance  test.  In-class  acceptance  testing  cannot  meet  all  of  these 
conditions,  but  certainly  a  simulation  can  be  done  which  at  least  meets 
conditions  2  and  4.  Documentation  can  be  presented  so  that  the 
maintainability  (condition  3)  is  clear. 

The  product  demonstrated  should  be  as  dose  to  the  product  to  be  delivered 
as  possible.  Discuss  the  potential  problems  caused  by  embedding  test 
scaffolding  or  a  test  harness  into  the  software  being  demonstrated.  This 
should  be  avoided  wherever  possible,  and  where  necessary  the  scaffolding 
should  be  removed  when  the  system  is  delivered  to  the  customer.  Point 
out  that  this  could  mean  that  the  system  on  which  acceptance  testing  is 
conducted  is  a  different  system  that  the  one  delivered. 

3.  Stress  that  these  tests  will  form  the  basis  for  acceptance  testing. 

ASSOCIATED  HANDOUTS: 

Acceptance  test  review 


1 


Lab  010 


Acctptance  TmI  R«vI«w 


The  Acceptance  test  is  normally  the  final  test  before  customer  acceptance  of  a  completed 

and  proven  product.  There  are  several  conditions  that  characterize  such  a  test. 

1 .  It  is  generally  done  with  customer  supplied  data  and  under  supervision  of  the 
customer  organization. 

2.  The  customer  is  concerned  with  the  ease  of  use  of  the  system  and  the  ease  of 
training  other  users. 

3.  The  customer  wants  a  system  which  is  easy  to  maintain.  Sometimes  final 
approval  requires  the  approval  of  the  maintenance  organization. 

4.  The  customer's  primary  question  is  if  the  system  meets  the  specified  requirements. 
This  is  most  easily  shown  by  publicly  executing  the  scenarios  of  the  test  plan. 

5.  The  customer  is  interested  in  more  than  just  the  software.  They  are  interested  in 
all  of  the  deliverables  including  tested  user  manuals  and  training  manuals, 
maintenance  and  update  information. 

6.  Programs  that  work  on  one  machine  may  not  work  on  another.  It  is  important  to 
try  to  test  in  an  environment  similar  to  the  one  in  which  the  system  will  be 
installed? 


In-class  acceptance  testing  cannot  meet  all  of  these  conditions,  but  certainly  a  simulation 
can  be  done  which  at  least  meets  conditions  2  and  4.  Documentation  can  be  presented 
so  that  the  maintainability  (condition  3)  is  clear.  The  product  demonstrated  should  be  as 
close  to  the  product  to  be  delivered  as  possible.  Do  not  embed  test  scaffolding  or  a  test 
harness  into  the  software  being  demonstrated. 
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projects  is  that  the  instructor  has  other  faculty  or  administrators  available  as 
information  resources. 


c.  Management  of  Teama. 

i.  General  Guidelines 

There  are  several  guidelines  to  the  development  and  management  of  team  projects. 

1.  Careftjlly  select  the  project.  Selecting  a  project  that  is  too  simple  allows  the 
students  to  succeed  in  spite  of  sloppy  development  (i.e.,  hacking)  a.id  does  not 
give  them  an  appreciation  for  the  complexity  of  software  development.  Selecting 
a  project  that  is  too  complex  presents  the  students  with  an  unmanageable  task. 
Student  satisfaction  with  the  learning  experience  is  greater  when  they  deliver  a 
functioning  system. 


2  Carefully  separate  the  roles  of  Instructor  and  customer.  Regardless  of 
whether  the  customer  is  real,  is  simulated  by  someone  other  than  the  instructor, 
or  is  role-played  by  the  instructor,  the  roles  should  remain  separate.  The  customer 
has  domain  expertise  and  understands  his/her  own  needs  but  does  not  necessarily 
have  computer  science  expertise.  The  instructor  has  computer  science  expertise 
but  does  not  necessarily  have  domain  knowledge  or  understand  the  customer’s 
needs.  During  interactions,  students  should  always  be  aware  of  who  is  responding 
-  the  customer  or  the  instructor.  When  role-playing,  a  simple  yet  effective  way  to 
make  this  visibly  apparent  is  for  the  instructor  to  have  an  instructor  hat  and  a 
customer  hat  (baseball  caps  work  particularly  well)  and  to  always  remember  to 
wear  the  appropriate  hat.  A  less  visually  apparent  method  is  to  simply  preface 
statements  appropriately  (e.g.,  "as  the  customer, ..."). 

3.  Provide  appropriate  acoeaa  to  the  Instructor  and  to  the  customer  and 
facilitate  interaction  between  students  and  customer.  The  level  of  accessibility 
will  be  different  for  the  instructor  and  the  customer.  Access  to  the  instructor  is 
typically  open.  Students  also  need  extensive  access  to  the  customer,  particularly 
during  requirements  elicitation,  but  that  access  should  be  more  limited.  Meetings 
with  the  customer  need  to  be  scheduled,  as  they  would  be  in  the  real  world. 

4.  Use  team  projects  rather  than  Individual  projects.  Team  projects  require 
commun'rcatron  between  team  members  as  well  as  with  the  instructor  and 
customer  and  better  reflect  the  real  world.  The  number  of  projects  to  be  managed 
simultaneously  by  the  instructor  is  reduced.  Teams  of  four  to  six  students  are 
appropriate. 


5.  Solve  the  problem  before  aeeigning  K.  Prior  to  assigning  the  project,  the 
instructor  should  work  out  a  solution,  at  least  through  design.  This  will  assure  that 
the  instructor  is  familiar  with  the  problems  that  the  students  will  face  during 
development. 

6.  Provide  appropriate  steering  to  student  teams.  While  the  students  should 
define  the  requirements  and  develop  a  solution  on  their  own,  appropriate  steering 
away  from  known  pitfalls  or  overiy  complex  solutions  will  increase  the  chances  for 
success.  Steering  students  away  from  premature  concentration  on  implementation 
details  is  often  necessary. 

7.  Require  deliverables  other  than  the  source  code.  Appropriate  deliverables 
such  as  requirements  documents,  design  documents,  and  test  plans  and  results 
should  be  required  of  the  students.  Otherwise,  students  can  resort  to  old  habits 
of  concentrating  strictly  on  implementation. 


ii.  Peer  and  Project  Evaluation 

Manaalno  the  Small  Protect  Teams 

In  the  small  project  a  single  team  of  students  works  on  all  phases  of  the  software 
development.  For  this  type  of  team  structure,  a  peer  evaluation  only  has  to  address 
intra-team  issues.  Because  of  the  relatively  short  duration  of  this  project,  we  only  use 
a  peer  evaluation  at  the  end  of  the  project.  Thus,  in  this  case  peer  evaluations  do  not 
help  to  identify  team  issues  such  as  some  students  failing  to  carry  their  share  of  the 
load.  These  are,  however,  identified  by  team  meeting  reports  and  other  interactions 
with  students  and  student  teams  during  the  project.  In  the  peer  evaluation  we  have 
found  it  useful  to  ask  each  student  about  their  own  as  well  as  every  other  team 
member’s  contribution.  Students  are  less  prone  to  exaggerate  their  own  performance 
and  accomplishments  if  they  are  aware  that  other  students  are  also  describing  their 
work.  This  question  also  helps,  when  students  understate  their  own  contribution  to  the 
project.  In  general  we  have  found  the  question  about  what  sequence  they  would  re¬ 
hire  their  own  teammates  to  be  a  useful  question  doing  most  stages  of  development. 
A  sample  peer  evaluation  follows. 
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GAZEBO  TEAM:  PEER/SELF  EVALUATION 


NAME: 


Your  rosponses  are  confidential  and  will  be  aeen  only  by  the  inetructora.  Be 
completely  honeet.  Uee  back  for  additional  commenta. 


1 .  Evaluate  the  performance  of  each  team  member,  including  yourself  with  respect 
to  each  of  the  following  questions  by  indicating  SA  (strongly  agree),  A  (agree),  D 
(disagree),  or  SO  (strongly  disagree). 


STUDENT 

1  2  3  4  5  6 


He/ahe  took  a  fair  share  of  the 
responsibility  and  work. 


He/she  took  a  leadership  role. 


He/she  kept  aware  of  the  project’s 
problems  and  progress. 


He/she  is  knowledgeable  of  the 
tools  and  techniques  used. 


He/she  attended  meetings  and 
cooperated  with  rest  of  team. 


He/she  gave  an  honest  effort 
and  completed  tasks  on  time. 


I  would  choose  to  work  with 
him/her  on  another  project. 
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2.  Complete  Columns  A  and  B  for  each  team  member,  including  yourself. 


COLUMN  A:  Enter  -t-,  or  -  as  follows. 

•f  means  this  person  made  a  significant  contribution  to  the  team  and  should 
be  given  a  bonus;  their  individual  project  grade  should  be  higher  than  the 
team  grade. 

«  means  this  person  did  their  share;  their  individual  project  grade  should 
be  equal  to  the  team  grade. 

means  this  person’s  performance  was  less  than  adequate  and  his/her 
individual  project  grade  should  be  lower  than  the  team  grade. 

COLUMN  B:  Describe  his/her  major  contributions. 

(A)  (B) 

TEAM  MEMBER  MAJOR  CONTRIBUTIOWS> 

Student  Namel 


Student  Name2 


Student  Name3 


Student  Name4 


Student  Names 


Student  Names 
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3.  For  each  item  below,  rate  your  team’s  performance  and  deliverables  produced. 
UN8  represents  unsatisfactory  and  EXC  represents  excellent. 


(a)  Interaction  with  user  in  understanding/defining  requirements 
BELOW  ABOVE 

UNS  AVG  AVG  AVG  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(b)  Configuration  Item  1  -  narrative  description  (abstract)  of  project  and 
requirements  list. 

BELOW  ABOVE 

UNS  AVG  AVG  AVG  EXC 


(c)  Configuration  Item  2  -  analysis  documents:  context  diagram,  leveled  data 
flow  diagrams,  data  dictionary. 

BELOW  ABOVE 

UNS  AVG  AVG  AVG  EXC 


(d)  Configuration  Item  3  •  design  documents:  system  architecture  (structure 
chart  and  external  description  of  modules  and  interfaces). 

BELOW  ABOVE 

UNS  AVG  AVG  AVG  EXC 

I  I  I  I  I  I  I  I  I 


(e)  Configuration  Items  4  and  5  -  test  plan  (classes  of  tests  for  each 
requirement);  test  scenarios  (specific  tests,  input,  expected  output,  etc.) 

BELOW  ABOVE 

UNS  AVG  AVG  AVG  EXC 


(f)  Configuration  Items  6  and  7  -  documented  source  code;  executable. 

BELOW  ABOVE 

UNS  AVG  AVG  AVG  EXC 
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(g)  Configuration  Item  8  -  cfc)cufnentitk)n  of  testing;  aooeplanoe 
plans,  documentation,  etc. 

BELOW  ABOVE 

UN8  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(h)  Configuration  Item  7  -  Acceptance  test  review 
BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 
I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(i)  Overall,  rate  the  your  team's  performance  for  the  entire  project? 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 
I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(j)  Overall,  the  tools  team  and  the  materials  they  have  produced  have  been 
NO  LITTLE  MUCH 

HELP  HELP  OK  HELP  HELP 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


4.  If  you  had  to  do  this  project  again  and  were  in  charge  of  hiring  personnel,  in 
what  order  would  you  rehire  the  team?  In  other  words,  who  would  be  the 
person  on  your  team  you  would  rehire  first,  second,  third,  etc.?  (Be  sure  to 
include  yourself). 

1. 


2. 


3. 

4. 

5. 

6. 
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in  addition  to  a  peer  evaluation,  we  use  a  project  evaluation  form.  We  do  not 
comment  on  a  particular  students  contribution  on  this  form.  We  comment  on  the 
quality  of  the  delivered  product  giving  a  clear  grade  for  the  quality  of  the  product.  We 
also  include  an  individual  student  grade  for  their  contribution  to  the  project.  This  grade 
may  differ  significantly  from  the  product  grade.  A  sample  of  a  completed  small  project 
evaluation  follows. 
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PROJECT  1  EVAUIATION:  Fm  AND  SECURITY  ALAMi  SYSTEM 


TEAM  MEMBER: _ 

TEAM  PRODUCT  GRADE:  TEAM  MEMBER'S  GRADE: 


COMMENTS  ON  DELIVERED  PRODUCT _ 

TImm  comiiMfits  pMlaIn  to  tho  doUvorod  ooflwfaio  product  and  art  not 
naoaaaarHy  raflaetivo  of  tha  tima  and/or  effort  axpandad. 

OVERALL  PACKAOmO 

Product  gives  appearance  of  having  been  thrown  together  up  to  the  last  minute, 
including  some  Hems  being  crossed  out  and  others  being  penciled  in. 

NARRATIVE  DESCRIPTION 

In  paragraph  7,  "same  span  of  time  .... "  is  stili  too  vague  to  be  tested. 
REQUIREMENTS  LIST 

#9  and  Footnote  are  inconsistent  wHh  one  another. 

#13,  #15:  indentation  erratic. 

#20:  incident  reports  and  frequency  reports  never  fully  defined. 

CONTEXT  DIAQRAM,  DFDa,  DATA  DICTIONARY 

Many  Hems  missing  from  data  dictionary,  including: 

Notify 

incident  report 
Frequency  report 
Incidents 

Signal  to  Fire  Equipment 
Signal  to  Warning  Device 
Signal  to  LocK/Unlock 
Room  Function 

No  data  stores  defined  in  data  dictionary. 
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Project  1  Evaluation  •  oont 


Use  of  "Flag”  in  data  dictionary  is  atiM  awkward.  It  would  be  much  more 
meaningful  to  do  sometMng  like  the  following: 

Hazard  ievel  -  High  |  Normal 
Type  ■  Rre  |  Security 

Alarm  condition  «  In-service  1  Out-of-Service 
etc. 

In  some  cases,  more  meaningful  names  could  easily  be  used;  for  example 
Type  is  stiH  too  vague. 

Context  diagram  and  DFD  are  not  balanced. 

DFD  is  rough;  far  from  form  expected  in  fir^shed  product. 

No  leveling  of  DFD. 

Transform  1  has  no  output. 

Transform  2  has  no  input. 

As  shown  in  model,  SetUpFile  should  be  an  external  entity. 

DESIGN  DOCUMENTS 

No  external  description  of  modules  and  interfaces  submitted. 

Various  inconsistencies  or  omissions  in  structure  chart;  for  example  Get  Info 
(page  2)  doesn't  return  any  information. 

Module  (and  procedure)  names  should  always  be  as  descriptive  as  possible 
and  consist  of  Verb  and  Object. 

CODE 

Design  and  code  are  inconsistent. 

In  places  it  is  tough  to  distinguish  between  test  modules  and  product  modules; 
for  example  the  OurTime  procedure. 

Programming  standards  were  not  foiiowed  In  several  aspects  including  identifier 
dictionaries,  input  and  output  descriptions,  use  of  meaningful  identifier  names 


Project  1  EvakMtlion  -  corn 


(for  example,  look  at  TimeCompare  and  TImeSulitract). 

Inconsistent  documentation  blocks  (for  example,  none  on  Ink  and 
CailProoedures). 

Comments  *  look  at  11.7  of  programming  standards. 

What  Is  purpose  of  procedure  CallProcedures? 

TEST  PLAN,  TEST  RESULTS 

Test  categories  too  broad:  for  exam^^' ;  consider  Section  C  (Alarm  Responses)  - 
these  need  to  be  broken  tkm  vther  to  adequately  test  system. 

Test  procedure  form:  (a)  all  look  IHte  low-level  unit  tests;  (b)  all  end  with  ttie 
generic  statement  ”Ve^  test  data  is  output  to  test  result  file.”  Should  also 
worry  about  correctness  of  output. 

Test  results  somewhat  confusing  and  appear  inadequate;  not  mappable  to  test 
procedures. 
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Managing  the  Extended  Protect  yams 


The  extended  project  introduces  some  new  complications  in  managing  projects.  First, 
since  it  is  a  multi-semester  project  there  may  be  new  students  joining  the  project  as 
well  as  students  leaving  the  project  at  ite  mid-point.  The  problems  of  training  and 
familiarizing  the  new  students  with  the  project  are  reduced  here  by  having  all  milestone 
information  ready  for  the  second  semester  of  the  project.  There  is  a  virtue  to  the 
second  semester.  It  provides  the  opportunity  to  use  the  information  you  learned  about 
the  student  team’s  dynamics  in  the  first  semester.  Using  this  information,  teams  can 
be  restructured  to  reduce  personal  conflicts  in  the  second  semester,  and  to  maximize 
the  use  of  individual  student  skills.. 

The  extended  project  introduces  a  new  management  problem,  intra-team  dependency. 
There  are  several  techniques  to  facilitate  communications  between  teams.  One  tool 
we  use  is  to  appoint  a  team  liaison  to  other  teams.  It  is  critical  to  project  success  that 
the  teams  work  together  toward  a  common  goal.  Sometimes  when  problems  arise 
there  is  a  tendency  for  the  teams  to  compete  against  each  other  or  blame  each  other 
for  problems.  In  managing  an  extended  project,  one  must  examine  the  status  of  the 
project  at  several  points  to  help  keep  it  on  track.  There  should  be  at  least  two  peer 
evaluations;  one  at  the  semester  break  and  one  at  the  end  of  the  project.  There  are 
numerous  opportunities  for  product  evaluation,  e.g.,  reviews  and  inspections, 
comments  on  milestone  documents,  etc.  These  reviews  are  directed  at  individual 
teams.  Sometimes  we  have  used  a  composite  evaluation  document,  so  that  each 
team  was  made  aware  of  the  strengths  and  weaknesses  of  their  own  work  as  well  as 
others  team's  work.  Because  student’s  function  in  a  variety  of  roles  on  a  variety  of 
teams,  it  helps  avoid  confusion  to  place  the  students  names  on  the  form  for  each 
team. 

The  extended  project  peer  evaluation  is  more  complicated  because  of  the  intra-team 
communications.  A  mid-project  and  end  of  project  peer  evaluation  form  for  a  student 
project  called  Third  Eye"  follow.  This  was  an  automated  plagiarism  detection  program. 
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THIRD  EYE  PROJECT  MID-POINT  EVALUATION 


Responses  are  confidential  and  will  be  seen  only  by  the  instructors.  Be  completely 
honest  in  rating  the  following  from  your  perspective.  In  the  scale  used,  UNS 
represents  unsatisfactory  and  EXC  represents  excellent.  Use  back  for  additional 


comments. 

Configuration  management  plan 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 


Requirements 

BELOW  ABOVE 

UNS  AVG  AVQ  AVQ  EXC 


COMMENTS: 


Test  Plan 


BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 


COMMENTS: 


Overall,  the  Third  Eye  team 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


Configuration  manager 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 


COMMENTS: 


Users  manual 


BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 


COMMENTS: 


Preliminary  design 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 


COMMENTS: 


COMMENTS: 
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THIRD  EYE  PROJECT  MID-POINT  EVALUATION 


TEAM:  REQUIREMENTS  *  MEMBER: _ 

Complete  the  following  for  each  member  of  the  team,  including  yourself. 

In  COLUMN  A,  describe  his/her  contributions  to  the  project. 

In  COLUMN  B,  select  VS  (very  satisfied),  S  (satisfied),  D  (dissatisfied),  or  VD 
(very  dissatisfy)  to  fill  in  the  blank  in  the  statement  below. 

"I  am _ with  his/her  work  on  the  team.” 

(A)  (B) 

TEAM  MEMBER  _ CONTRIBUTION(S) _  gATIgFACTIQN 


A  similar  form  is  completed  by  each  member  of  the  other  project  teams  (user 
interface,  test  plan,  preliminary  design,  etc.) 
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THIRD  EYE  -  END  OF  PROJECT  PEER  EVALUATION 
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Configunrtiofi  Managemtiit 


Ovvrill,  thm  Third  Ey«  System 

BELOW  ABOVE  BELOW  ABOVE 

UN8  AVQ  AVQ  AVQ  EXC  UNS  AVO  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1  I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS:  COMMENTS: 


2.  Characterize  the  interactions  between  the  indicated  teams  using  the  following  scale 
by  circling  the  most  the  most  appropriate  descriptor. 

VN  >  yery  Non-productive  A  «  Adequate  VP  »  Very  Productive 
N  «  ^on-productive  P  »  Productive 

a)  Preliminary  design  team  &  Detailed  design  team  —  VN  N  A  P  VP 

b)  Detailed  design  team  &  Code  and  unit  test  team  —  VN  N  A  P  VP 


c)  Detailed  design  team  &  Testing  team - VN  N  A  P  VP 

d)  Code  &  unit  test  team  &  Testing  team - VN  N  A  P  VP 


e)  Detailed  design  team  &  Configuration  manager - VN  N  A  P  VP 

f)  Code  and  unit  test  team  &  Configuration  manager  —  VN  N  A  P  VP 

g)  Testing  team  &  Configuration  manager - VN  N  A  P  VP 
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THIRD  EYE  -  END  OF  PROJECT  PEER  EVALUATION 


Complete  the  following  for  each  member  of  the  team,  Including  yourself. 

In  COLUMN  A,  describe  his/her  contributions  to  the  project. 

In  COLUMN  B,  select  VS  (very  satisfied).  8  (satisfied).  D  (dissatisfied),  or  VD  (very  dissatisfied) 
to  fill  in  the  blank  in  the  statement  below. 


"I  am 


with  his/her  work  on  the  team." 


A  similar  form  is  completed  by  each  member  of  the  other  project  teams  (code  &  unit 
test,  testing,  etc.) 
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4.  Imagine  that  $2000  in  bonuses  is  to  be  distributed  among  the  THIRD  EYE  Project  team 
members.  Half  of  it  ($1000)  is  to  be  distributed  based  on  the  intellectual  contribution  to  the 
project,  i.e.,  significant  ideas  and  solutions  contributed.  The  other  half  ($1000)  is  to  be 
distributed  based  on  amount  of  individual  effort  contributed  to  the  project. 

Distribute  the  bonuses.  If  vou  wish,  justify  each  of  the  assignments.  Be  very  specific;  list 
some  especially  significant  contributions  for  which  the  team  member  should  be  proud  or 
where  the  project  was  made  more  or  less  difficult  because  of  it. 


$1000  $1000 

Protect  Member  Name  concepts  effort  JUSTIHCATION 
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iii  Regular  Team  Meeting 


Instead  of  waiting  for  students  to  submit  project  deliverables  to  track  a  project,  we 
require  team  meeting  reports  from  each  team  for  every  team  meeting.  This  allows  us 
to  keep  track  of  their  work  without  being  intrusive  at  team  meetings.  The  team 
meeting  report  template  included  on  the  following  page  is  provided  to  each  team.  The 
team  meeting  report  form  is  intended  to  develop  a  task  oriented  structure  for  the 
meetings.  After  the  first  meeting,  the  tasks  assign^  at  the  previous  meeting  constitute 
the  primary  agenda  for  the  next  meeting.  The  status  of  the  work  on  every  task  is 
reported  and  discussed  at  the  meeting.  The  problem  is  either  reported  as  resolved  or 
a  new  approach  is  decided  upon  and  assigned.  This  method  of  documenting  meetings 
helps  to  give  them  a  structure  and  a  goal.  It  also  clearly  documents  individual 
responsibility  for  project  tasks.  There  is  also  a  place  to  report  general  problems.  This 
is  especially  useful  information  to  the  instructor. 
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TEAMMiETINQ  RECORD 


TEAM  ID: 

DATE:  LOCATION: 

START  TIME: 

END  TIME: 

MEMBERS  PRESENT:  ABSENT: 


ITEM 


PERSON  RESPONSI. 


1. 


RESOLUTION: 


2. 


RESOLUTION: 


3. 


RESOLUTION: 
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8UIMIARY  (Nmv  ItMMt,  dIffleiilllM, 


TASKLIST 
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i.  Scheduling 


It  is  essential  to  carefully  control  both  inter-team  and  intra-team  activity  if  the  inverted 
functional  matrix  organization  is  to  be  effective.  Objectives  in  team  management 
include  disciplined  system  deveiopment  and  overcoming  student  tendencies  to 
procrastinate  and  become  easiiy  distracted  from  a  task.  Pra^ical  management 
techniques  for  accomplishing  these  objectives  include  an  effective  project  start-up,  a 
software  project  management  plan,  preliminary  and  final  in-dass  revfews  of  team 
deliverables,  regular  team  status  reports,  and  inch  pebbles  plans  when  appropriate. 

Assigning  all  students  to  teams  that  begin  work  at  once  on  the  project  is  important 
because  it  sets  the  tone  for  the  whole  project.  It  is  equally  important  that  these  teams 
be  coordinated  so  that  each  has  specific  tasks  to  be  undertaken  immediately.  Thus, 
the  configuration  manager,  the  requirements  team,  the  user  interface  team,  the  test 
plan  team,  and  the  tools  team  are  given  specific  assignments. 

The  configuration  manager  is  charged  immediately  with  developing  a  first  draft 
configuration  management  plan.  The  configuration  management  plan,  developed  by 
the  configuration  manager  and  presented  to  the  class  for  review,  must  be  in  place  prior 
to  the  development  or  submission  of  any  other  configuration  items. 

All  teams  are  informed  of  their  specific  deliverables.  The  requirements  team 
immediately  begins  the  process  of  eliciting  requirements  from  the  customer.  Similarly, 
the  user  interface  team  interacts  with  the  user  and  the  requirements  team  to  begin 
establishment  of  user  interface  requirements  and  a  format  for  the  preliminary  user 
manual.  The  test  plan  team  begins  ^rk  on  a  test  plan  shortly  after  requirements 
analysis  is  underway.  The  tools  team  develops  training  materials  and  documentation 
for  project  support.  With  this  start-up  strategy,  all  students  are  immediately  involved 
in  the  project. 

All  projects  were  carefully  scheduled.  We  have  found  that  unscheduled  software  is 
vaporware.  Each  project  has  a  deliverable  schedule  which  drives  the  project.  These 
are  modified  software  project  management  plans. 

A  software  project  management  plan  (SPMP)  describes  the  sequence  of  activities 
needed  to  successfully  develop  a  particular  software  product.  It  minimally  includes  ail 
major  milestones  and  their  due  dates,  the  dates  when  teams  are  scheduled  to  begin 
work,  and  the  list  of  configuration  items  (i.e.,  items  to  be  placed  under  configuration 
control).  If  more  detail  is  desired,  the  SPMP  can  also  iridude  intermediate  targets 
such  as  walkthroughs  and  inspections.  Below  is  a  sample  small  project  software 
project  management  plan  and  an  extended  project  SPMP  used  through  preliminary 
design.  To  be  effective,  the  plan  should  be  hancM  out  when  the  project  is  introduced. 
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Benween  delivwBbIts,  the  plan  should  te  refsfanoad  during  class  and  8 
how  they  are  progfeaaing  and  if  they  need  any  help  meeting  their  due  dates.  Justas 
the  SPMP  guides  the  students  through  the  prpj^  it  also  helps  the  instructor  in 
managing  the  project 
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Date 

Due 

Descriotlon 

Th  9/2 

Customer  requirements  statement  distributed;  begin  requirements 
analysis  and  specification 

Th  9/9 

Draft  CI-1 

Narrative  description  (abstract  and  requirements  list 

Tu  9/14 

Draft  CI-2 

CD.  1st  level  DFD,  and  DD 

Th  9/16 

Begin  design  ;  begin  test  plan 

Tu  9/21 

CI-1.  CI-2 

Requirements  review  preaentatien 

Th  9/23 

Draft  CI-3 

Design  documents:  system  architecture  -  structure  chart,  external 
descriptions  of  modules  &  interfaces 

Draft  CI-4 

Test  plan:  classes  of  tests  for  each  requirement 

Tu  9/28 

CI-3,  CI-4 

Begin  design  of  specific  test  cases 

Th  9/30 

Continue  modifications  based  on  internal  reviews  and  customer 
feedback;  continue  design  of  test  cases 

Tu10/7 

CI-5 

Test  cases:  specific  tests,  their  input  and  expected  output  and  their 
relation  to  requirements 

Tu  10/12 

Design  review  presentation 

Modify  analysis,  design,  test  plan  documents  based 
on  review;  begin  coding 

{Internal  code  reviews,  unit  testing,  system  testing} 

Tu  10/26 

CI-6,  CI-7 

Documented  source  code.  Executable  code 

Th  10/28 

CI-8 

Acceptance  Test:  documentation  of  test  cases  and  their  relation  to  the 
test  f^an  and  documentation  of  the  consistency  of  the  source  code 
structure  with  the  architectural  design; 

CI-9 


Prt— ntitlon  of  ty ttom  to  cuotomor 
Deliver  "package”  of  all  Cl's 


NOTES:  All  Confiouration  Hams  (Cl’s)  are  due  at  the  BEGINNING  of  class  on  the  specified 

dates. 

All  preswitation/review  items  are  distrttxfted  to  designated  re>rtewers  24  hours  prior  to 
the  presentation/review. 

Ail  team  members  are  expected  to  participate  in  a  meaningful  role  in  at  least  one  of 
their  team’s  review  presentations. 

Configuration  items: 

CI-1  Narrative  description  (abstract)  and  requirements  list 

CI-1  Context  diagram,  leveled  data  flow  diagrams,  data  dictionary 

Ci-3  Design  documents:  software  system  architecture  -  structure  chart, 
external  descriptions  of  modules  and  their  interfaces 

CM  Test  plan:  classes  of  tests  for  each  requirement 

CM  Test  cases:  specific  tests,  their  input  and  expected  output  and  their 

relation  to  requirement 

CM  Documented  source  code 

CI-7  Executable  code 

CM  Documentation  of  test  cases  and  their  relation  to  the  test  plan  and 

documentation  of  the  consistency  of  the  source  code  structure  with  the 
architectural  design 

CM  Complete  package 

Additional  details  regarding  format  of  Cl’s  will  be  provided  in  class. 
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PATE 

SUA 

Daacrintion 

1(V28 

Customer  request  prasenlad. 

11/02 

Team  assignments  announosd  and  roles  defined. 

Start  development  of  configuration  marwQsment  plan  (CMP),  preliminary 
requirements  (P_REQ).  preliminary  tost  plan  (PJTP),  and  preUminaiy 
user’s  manual  (P.UM). 

11/09 

CI-1 

CMP  delivered  and  presentation  to  teams. 

11/11 

Ci-2 

P_REO  delivered  arxi  presentation  to  teams  arxJ  customer. 

11/16 

CI-3 

P_TP  delivered  and  presentation  to  teams. 

CM 

P.UM  delivered  and  presentation  to  teams. 

11/18 

Requirements  review.  Preliminary  design  begins. 

11/23 

CI-5 

Requirements  revised  based  on  review,  delivered,  baselined. 

12/02 

Preliminary  design  review. 

12/07 

Ci>6 

Preliminary  design  delivered  and  baselined. 

12/09 

CI-7 

Final  test  plan  delivered  and  baselined. 

CI-8 

Final  user  manual  delivered  and  baselined. 

Entire  project  package  submitted. 

NOTES:  Ail  Configuration  items  (Cl’s)  are  due  at  the  BEGINNING  of  class  on  the  specified 

dates. 

All  presentation/review  Herns  are  distributed  to  designated  reviewers  24  hours  prior  to 
the  presentation/review. 

All  team  members  are  expected  to  participate  in  a  meaningful  role  in  at  least  or>e  of 
their  team’s  review  presentations. 


ii.  Configuration  Management 

The  SPMP  underscores  the  role  and  visibility  of  configuration  management.  The 
configuration  management  plan  establishes  the  place  of  the  configuration  manager  in 
the  development  process.  Documents  submitted  for  final  review,  as  specified  on  the 
SPMP,  are  immediately  placed  under  CM  and,  therefore,  configuration  control.  The  first 
document  placed  under  configuration  control  is  the  configuration  management  plan.  A 
minimum  form  of  configuration  control  can  be  established  by  setting  up  a  directory  which 
holds  items  placed  under  configuration  control  and  to  whidi  only  the  configuration 
manager  has  write  access  and  other  class  members  have  read  access. 

A  good  configuration  manager  makes  the  whole  development  process  easier.  Both  the 
instructor  and  the  configuration  manager  must  promote  the  configuration  management 
plan.  Active  and  visible  support  for  the  configuration  manager  from  the  instructor  is  also 
necessary.  The  instructor  acts  as  the  configuration  control  board  in  handling  change 
requests.  The  turn-around  time  on  change  requests  must  be  minimized  to  avoid  the 
perception  that  CM  impedes  rather  than  expedites  development.  Samples  of  CM  plans 
and  change  requests  are  contained  in  the  case  study  in  section  V. 


e.  PROJECT  IDEAS 

There  are  sample  projects  scattered  throughout  this  document.  For  example,  some 
project  examples  are  contained  in  LabOOt .  Additional  project  ideas  are  listed  below. 
Many  of  these  were  drawn  from  other  software  engineering  texts. 

In  selecting  projects  for  a  course  there  are  a  number  of  decisions  you  can  make  which 
will  help  limit  the  project  selection.  Some  of  the  generic  questions  that  can  be  asked 
are:  Is  the  system  one  that  is  intended  to  be  used  by  someone?.  Is  it  an  complete 
application  or  is  it  a  piece  of  a  larger  one?.  What  special  interfaces  are  available,  and 
what  type  of  application  is  it? 

Databases  are  easily  understandable  types  of  projects.  These  systems  are  specialized 
data  storage  and  retrieval  systems,  it  is  interesting  when  the  algorithms  involve 
concurrency  management,  retrieval,  etc.  These  projects  involve  a  client  server  model 
where  the  server  manages  access  to  some  database.  The  second  group  of  items 
require  very  specific  customer  interfaces. 

1 .  lottery  manager 

student  Government  Association  Voting  system 
scientific  reference  library 

personal  data  management  systems 

e.g.,  wine  cellar,  record  albums,  books,  videotapes,  etc. 
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poUingNoting  system 

library  managafnent  system  (books  &  patrons) 

store  sales  activity 

genealogical  database 

softwrare  components  catalog 

photograph  library  sales  system 

student  record  syirtem 

student  laborato^  management  system 

course  scheduling  and  management  system 

university  department  information  management 

draw  diagrams 

generate  relational  database  scheme 
2.  slot  machine 

vending  machine  •  coin  slot  &  dollar  Mil  slot 
electronic  banking 
electronic  mail  system 
student  registration  system 
airline  reservation  system 

electronic  town  meeting  (or  other  grmjp  communication  forum) 

bulletin  board/news  system 

electronic  banking  (e.g.,  ATM  system) 

group  diary  and  appointment  management  system 

Some  faculty  have  students  build  software  utilities  similar  to  ones  done  in  operating 
systems  classes.  They  write:  assembles,  compilers,  linker/loaders,  or  search/replace 
utilities.  There  are  several  drawbacks  to  such  projects.  They  do  not  make  a  dear  break 
between  software  engineering  techniques  and  the  methods  they  may  use  in  operating 
systems  dasses.  These  projects  still  foster  thought  of  development  being  the 
development  of  a  program  rather  than  a  system  with  complex  user  interaction. 

To  overcome  the  later  difficulty,  it  is  important  to  develop  systems  with  user  interaction. 
There  are  several  user  application  sterns  that  can  be  developed.  Some  of  these 
systems  require  extensive  domain  knowiedste-  Projects  like  this  indude: 

economic  analysis  systems 
library  tracking  systems 
graduate  tracking  systems 
Departmental  calendar  (Jones) 

Group  diary  &  appointments  system  (Sommerville,  p  45  of  inetructor’s  guide) 
Structure  extractor  (Jones)  •  extracts  from  source  code:  invocation  hierar^y,  DFD, 
object  visibility  chart.  Nassi*Schneiderman  chart,  etc.  (See  Sommerville  p  46  of 
instructor’s  guide) 

CS1  Karel-Like  Robot 
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Program  comparer;  plagiarism  detector 
Room  scheduler 
Football  Rating  system 
Automobile  Rental  System 

Fire  and  security  alarm  monitoring  system  (Sommerville,  p  43  of  IG) 

Police  vehicle  command  and  control  system  (Sommerville,  p  42  of  IG) 

software  metric  tool  e.g.,  static  structure  analysis  for  a  collection  of  modules 

source-code  management  system  (change  control,  reporting,  data  collection) 

program  visualizer  (structure,  etc.) 

satellite  tracking  program 

tax  return  calculation 

hypertext  authoring  system 

spreadsheet  calculator 

office  automation  system 

expert  system  software 

computer  opponent  for  game  playing  (e.g.,  tic-tac-toe,  otheilo) 

simf^e  flight  simulator 

simulate  evolution  (game  of  life) 

revenue  projector  for  concert  administration 

document  concordance  (generating  index) 

personal  calendar 

hcusehold  budget 

simulate  a  scientific,  pocket  calculator 
newspaper  typesetter 
scoring  athletic  events 
simple  diagram  editor  (any  type  of  diagrams) 
interactive,  symbolic  manipulation  of  polynomials 
computer  animation,  animated  presentation  system 
diagram  editor  for  electric  power  distribution  systems 
police  vehicle  command  and  control  system 
overhead  projector  transparency  preparer 

Sources  of  project  ideas  are  listed  in  the  software  engineering  bibliography.  Texts  that 

are  especially  useful  in  this  regard  are  the  books  by:  Blum,  Booch,  Frakes,  Lamb,  von 

Mayrhauser,  Mynatt,  Rakos,  Rumbaugh  et  al.,  Schach,  and  Sommerville. 


f.  Inverted  Functional  Matrix  Team  Organization 

The  inverted  functional  matrix  organization  and  management  is  described  in  the 
attached  paper  which  has  been  submitted  to  SIGCSE  95  for  presentation  and 
publication.  The  figures  referred  to  in  the  paper  appear  elsewhere  in  this  report. 
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The  Inverted  Functional  Matrix  -  A  New  Approach 
to  Project  Intensive  Software  Engineering  Courses 

Donald  Qotterbam,  Robert  Riser 
East  Tennessee  State  University 

Suzanne  Smith 
Converse  College 


1 .  Introduction 

The  inverted  functional  matrix  provides  a  new  approach  to  organizing  and  managing  projects 
in  software  engineering  courses.  It  provides  realistic  experience  in  the  development  of  large 
software  products.  Kurtz  [6]  has  identified  three  typical  approaches  to  class  project 
organization:  multiple  teams  of  students  independently  developing  the  same  project,  multiple 
teams  developing  different  projects,  or  one  class  project  divided  into  programming  subtasks 
where  each  subtask  is  assigned  to  a  team.  However,  these  models  do  not  simulate  real- 
world  development  of  large  projects  as  accurately  as  the  inverted  functional  matrix 
organization. 

This  article  describes  the  details  of  the  project  organization,  the  team  structure,  the 
management  and  assessment  issues,  and  the  benefits  of  this  approach  beyond  other 
models. 


2.  Inverted  Functional  Matrix  Organization 

The  inverted  functional  matrix  organization  incorporates  attributes  of  both  the  functional  and 
matrix  models  identified  by  Fairley  [4].  This  approach  involves  a  single  significant  class 
project  where  the  software  development  process  model  is  used  as  the  basis  for  project  team 
organization.  Individual  teams  are  responsible  for  different  life  cycle  phases.  The  columns 
of  the  matrix  are  the  development  teams,  and  the  rows  are  the  students.  This  matrix 
organization  is  inverted  because  the  students  are  distributed  to  multiple  functional  teams  of 
a  single  project  rather  than  to  a  single  functional  team  which  is  then  distributed  across 
multiple  projects. 

The  inverted  functional  matrix  organization  is  independent  of  process  model.  It  has  been 
used  for  both  structured  development  and  otqect-oriented  development  in  classes  at  East 
Tennessee  State  University. 
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2.1.  Team  Organization 


The  partitioning  of  the  class  project  into  teams  reflects  the  division  of  any  software 
development  project  into  analysis,  design,  and  implementation  phases,  and  support 
functions.  The  teams  which  start  in  the  analysis  phase  are  the  requirements  team,  the  user 
interface  team,  and  the  test  plan  team.  The  teams  which  start  in  the  design  phase  are  the 
preliminary  design  team  and  the  detailed  design  team.  The  code  team  and  the  testing  team 
begin  during  implementation.  The  support  teams,  configuration  management  and  tools,  exist 
throughout  the  project.  The  Gantt  chart  (Figure  1)  shows  this  relationship. 

The  entire  class  is  organized  to  work  on  a  single  project,  and  all  students  serve  on  either 
multiple  teams  or  an  entire  life  cycle  support  team.  Figure  2  depicts  the  inverted  functional 
matrix  organization  for  a  class  of  size  fifteen;  this  organization  has  been  scaled  to  other 
class  sizes.  The  user  interface  team  operates  in  both  the  analysis  and  design  phases.  The 
support  teams,  configuration  management  and  tools,  operate  in  all  phases.  One  member 
of  each  analysis  and  design  team  is  designated  to  maintain  their  team’s  deliverables  until 
the  completion  of  the  project. 

The  choice  of  teams  to  which  a  given  student  is  assigned  is  significant  both  to  product 
quality  and  to  breadth  of  experience  to  be  gained  by  the  student.  To  protect  project 
integrity,  careful  attention  must  be  given  to  the  allocation  of  students  to  teams.  No  student 
is  assigned  to  two  teams  which  are  responsible  for  validating  one  another’s  work;  for 
example,  no  one  is  assigned  to  both  the  coding  and  the  testing  team.  Correctly  organized, 
teams  act  as  cross  checks  on  each  other  during  development.  For  example,  the  user 
interface  team  meets  independently  with  the  user,  while  the  requirements  team  meets  with 
the  customer.  During  the  requirements  review,  the  user  interface  team  can  help  validate  the 
requirements.  The  other  consideration  in  the  assignment  of  students  to  teams  is  the  breadth 
of  development  experience  gained  by  individual  students.  Members  of  the  support  teams 
experience  the  entire  life  cycle  while  on  a  single  team.  All  other  students  serve  on  an 
analysis  team,  a  design  team  and  an  implementation  team.  Members  of  the  requirements 
team  are  split  between  the  preliminary  design  and  detailed  design  teams  as  the  transition 
is  made  from  analysis  to  design.  The  test  plan  team  is  split  similarly.  The  user  interface 
team  remains  intact  through  the  design  phase.  As  the  transition  is  made  from  design  to  the 
implementation  phase,  each  of  the  teams  is  distributed  among  the  code  and  testing  teams. 
While  no  student  serves  on  every  team,  each  becomes  knowledgeable  of  the  functions  and 
products  of  all  teams  through  the  review  process  described  in  Section  3.4. 

2.2.  Team  Definition 

in  this  section,  the  teams  for  the  inverted  functional  matrix  organization  are  described 
according  team  the  purpose  and  tasks,  deliverables,  and.  where  applicable,  tools  used  by 
a  team.  Interactions  between  teams,  and  between  a  team  and  the  customer  or  a  team  and 
the  user  are  also  described. 

The  requirements  team  meets  with  the  customer  in  order  to  elicit,  analyze,  and  specify  the 
requirements  for  the  software  system.  They  develop  the  analysis  model.  For  example,  if 
structured  analysis  is  used,  the  analysis  model  includes  a  narrative  description  of  the 
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proposed  system,  a  list  of  requirements  (acceptance  criteria),  context  diagram,  leveled  data 
flow  diagrams  (DFDs),  data  dictionary,  and  process  specifications.  A  CASE  tool  is  used  to 
produce  the  context  diagram,  leveled  DFDs,  and  data  dictionary.  Such  tools  provide 
traceability  and  verifiability  between  tfie  diagrams  and  the  data  dictionary. 

The  user  interface  team  produces  all  user  documentation  for  the  system,  develops  user 
interface  requirements,  arid  designs  the  user  interface  of  the  system.  Their  deliverables  are 
the  preliminary  format  of  the  user  manual,  the  complete  user  manual,  and  the  detail  for  all 
user  interface  (e.g.,  required  menus,  forms,  screens,  reports,  commands).  A  prototyping 
tool  or  screen  generator  is  useful  here. 

The  test  plan  team  designs  the  subsystem  and  system  tests.  They  develop  the  test  plan 
which  includes  the  test  schedule,  order  of  integration,  checklist  of  tests  to  run  at  each  step 
of  integration,  and  traceability  of  tests  to  the  requirement(s)  being  testing.  They  also  design 
black-box  test  data  (i.e.,  test  data  based  on  the  requirements). 

The  preliminary  design  team  creates  a  preliminary  software  structure  of  the  system  based 
on  the  requirements  produced  by  the  requirements  team.  The  preliminary  design 
deliverables  are  the  system  components  (including  a  description  of  each  component’s 
functionality),  the  architecture  of  these  components,  the  interface  between  the  components, 
and  a  traceability  matrix  which  relates  a  component  to  the  requirement(s)  which  it  satisfies. 
CASE  tools  can  be  used  to  create  the  system  architecture,  specify  component  interfaces, 
and  describe  component  functionality. 

The  detailed  design  team  creates  the  algorithms  to  implement  the  system  structure  produced 
by  the  preliminary  design  team.  Detailed  design’s  deliverables  include  the  algorithms  for 
each  component  delineated  in  the  system  structure  and  a  traceability  matrix  which  relates 
each  algorithm  to  a  component  in  the  preliminary  design.  The  algorithms  can  be  specified 
by  notations  such  as  Nassi-Shneidermann  charts,  pseudocode,  or  flow  charts. 

The  code  team  produces  source  code  for  the  algorithms  created  by  the  detailed  design  team 
and  performs  unit  testing.  The  tested  source  code  is  the  deiiveraUe  for  the  code  team.  The 
minimal  tools  required  are  a  text  editor  and  a  compiler  for  the  specified  programming 
language;  however,  other  useful  tools  include  a  language-sensitive  editor  and  debugger. 

The  testing  team  implements  the  tests  described  in  the  test  plan  and  executes  these  tests 
in  order  to  verify  and  validate  the  software.  The  deliverables  of  the  testing  team  are  the 
white-box  tests  and  test  data  (i.e.,  data  which  exercises  the  logic  of  the  system)  and  the 
documented  test  results.  Finally  they  conduct  acceptance  testing.  Any  CASE  tools  which 
help  automate  the  testing  process  are  beneficial  to  this  team  and  the  code  team. 


The  tools  team  provides  training  and  ongoing  support  for  the  tools  and  environments  needed 
by  the  other  teams.  They  produce  instructional  materials  (e.g.,  written  tutorials  and  lectures) 
on  the  tools  and  environments.  These  instructional  guidelines  provide  the  basics  for  using 
a  tool  and  details  on  any  advanced  features  of  a  tool  to  which  a  team  needs  access. 
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The  configuration  management  (CM)  team  develops  and  implements  a  configuration 
management  plan.  This  team  is  in  existence  throughout  the  project  and  is  normally  a  one- 
person  team.  The  deliverables  are  the  configuration  management  plan  and  all 
documentation  necessary  for  its  implementation.  The  configuration  management  plan 
includes  documentation  standards,  configuration  item  control,  and  change  control. 

Some  of  the  interaction  between  teams  is  evident  in  the  descriptions  above.  Throughout  the 
development  process,  teams  produce  deliverables  which  are  needed  by  other  teams  to 
accomplish  their  tasks.  For  example,  the  preliminary  design  team  works  directly  from  the 
deliverables  produced  by  the  requirements  team,  and  the  detailed  design  team  works 
directly  from  the  deliverables  of  the  preliminary  design  team.  Other  interactions  are  also 
needed  for  the  teams  to  accomplish  their  tasks.  The  user  interface  team  communicates  with 
the  requirements  team  in  order  to  define  the  user  interface  and  develop  the  user  manual. 
The  test  plan  team  also  communicates  with  the  requirements  team  in  order  to  develop  tests 
and  test  data  based  on  the  requirements.  The  configuration  management  team  and  the 
tools  team  communicate  with  ail  other  teams  throughout  the  development  process. 

The  interaction  between  teams  and  the  customer  or  the  user  is  also  critical  for  the  success 
of  a  project.  Teams  which  have  extensive  communication  with  the  customer  or  user  are  the 
requirements  team,  user  interface  team,  and  preliminary  design  team.  This  communication 
takes  the  form  of  interviews  and  participation  in  reviews  of  the  deliverables  for  these  teams. 


3.  Managing  the  Teams 

It  is  essential  to  carefully  control  both  inter-team  and  intra-team  activity  if  the  inverted 
functional  matrix  organization  is  to  be  effective.  CX>jectives  in  team  management  include 
disciplined  system  development  and  overcoming  student  tendencies  to  procrastinate  and 
become  easily  distracted  from  a  task.  Practical  management  techniques  for  accomplishing 
these  objectives  include  an  effective  project  start-up,  a  software  project  management  plan, 
preliminary  and  final  in-class  reviews  of  team  deliverables,  regular  team  status  reports,  and 
inch  pebbles  plans. 

3.1.  Project  Start-Up 

Assigning  all  students  to  teams  that  begin  work  at  once  on  the  project  is  important  because 
it  sets  the  tone  for  the  whole  project.  It  is  equally  important  that  these  teams  be  coordinated 
so  that  each  has  specific  tasks  to  be  undertaken  immediately.  Thus,  the  configuration 
manager,  the  requirements  team,  the  user  interface  team,  the  test  plan  team,  and  the  tools 
team  are  given  specific  assignments. 

The  configuration  manager  is  charged  immediately  with  developing  a  first  draft  configuration 
management  plan.  The  configuration  management  plan,  developed  by  the  configuration 
manager  and  presented  to  the  class  for  review,  must  be  in  place  prior  to  the  development 
or  submission  of  any  other  configuration  items. 

All  teams  are  informed  of  their  specific  deliverables.  The  requirements  team  immediately 
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begins  the  process  of  eliciting  requirements  from  the  customer.  Similarly,  the  user  interface 
team  interacts  with  frie  user  and  the  requirements  team  to  begin  establishment  of  user 
interface  requirements  and  a  format  for  the  preliminary  user  manual.  'Hie  test  plan  team 
begins  work  on  a  test  plan  shortly  after  requirements  analysis  is  underway.  The  tools  team 
develops  training  materials  and  documentation  for  project  support.  With  this  start-up 
strategy,  ail  students  are  immediately  involved  in  the  project. 

3.2  Software  Project  Management  Plan 

A  software  project  management  plan  (SPMP)  describes  the  sequence  of  activities  needed 
to  successfully  develop  a  particular  software  product.  It  minimally  includes  all  mayor 
milestones  and  their  due  dates,  the  dates  when  teams  are  scheduled  to  begin  work,  and  the 
list  of  configuration  items  (i.e.,  items  to  be  placed  under  configuration  control),  if  more  detail 
is  desired,  the  SPMP  can  also  include  intermediate  targets  such  as  walkthroughs  and 
inspections.  Figure  3  is  a  SPMP  used  through  preliminary  design.  To  be  effective,  the  plan 
should  be  handed  out  when  the  project  is  introduced.  Between  deliverables,  the  plan  should 
be  referenced  during  class  and  students  asked  how  they  are  progressing  and  if  they  need 
any  help  meeting  their  due  dates.  Just  as  the  SPMP  guides  the  students  through  the 
project,  it  also  helps  the  instructor  in  managing  the  project. 

3.3  Configuration  Management 

The  SPMP  underscores  the  roie  and  visibility  of  configuration  management.  The 
configuration  management  plan  establishes  the  place  of  the  configuration  manager  in  the 
development  process.  Documents  submitted  for  final  review,  as  specified  on  the  SPMP,  are 
immediately  placed  under  CM  and,  therefore,  configuration  control.  The  first  document 
placed  under  configuration  control  is  the  configuration  management  plan.  A  minimum  form 
of  configuration  control  can  be  established  by  setting  up  a  directory  which  holds  items 
placed  under  configuration  control  and  to  only  the  configuration  manager  has  write 
access  and  other  class  members  have  read  access. 

A  good  configuration  manager  makes  the  whole  development  process  easier.  Both  the 
instructor  and  the  configuration  manager  must  promote  the  configuration  management  plan. 
Active  and  visible  support  for  the  configuration  manager  from  the  instructor  is  also 
necessary.  The  instructor  acts  as  the  configuration  control  board  in  handling  change 
requests.  The  turn-around  time  on  change  requests  must  be  minimized  to  avoid  the 
perception  that  CM  impedes  rather  than  expedites  development. 

3.4  Reviews 

In-class  reviews  are  used  as  quality  assurance  activities  for  deliverables.  Each  milestone 
on  the  SPMP  has  a  preliminary  and  final  review.  Reviews  help  students  manage  their 
team's  progress  in  producing  deliverables.  Preliminary  reviews  also  give  teams  early 
insights  into  the  deliverables  they  will  be  receiving. 

Before  any  review  is  conducted,  appropriate  review  techniques  [3, 7, 10]  are  discussed.  It 
is  important  to  stress  that  the  function  of  reviews  is  the  improvement  of  the  delivered  product 


and  that  problems  are  identified  but  not  solved  during  a  review. 


The  pattern  for  reviews  is  that  the  students  give  a  preliminary  review  presentation  in  which 
each  team  member  takes  an  active  role.  The  material  to  be  reviewed  is  distributed  prior  to 
the  review.  For  each  type  of  review,  the  class  is  given  a  review  preparation  form.  These 
forms  indicate  specific  items  which  are  to  be  addressed  in  the  review  by  the  presenting  team 
and  by  the  student  reviewers.  Figure  4  is  a  sample  of  this  form.  Each  student  is  expected 
to  have  carefully  read  the  review  material  and  to  act  as  a  reviewer.  The  team  responds  to 
questions  or  comments  from  the  reviewers.  Each  team  appoints  a  secretary  to  record  ail 
issues  raised  during  a  review.  After  the  preliminary  review,  the  team  revises  their 
deliverable  for  a  later  final  review.  The  final  review  is  conducted  in  the  same  manner  as  the 
preliminary  review.  After  the  final  review,  the  team  makes  any  remaining  adjustments,  and 
the  deliverable  is  put  under  configuration  management. 

Student  evaluations  have  been  very  favorable  to  the  review  process.  A  difficulty  for  the 
instructor  is  assuming  the  distinct  roles  of  instructor  and  customer  during  the  review.  The 
customer  expertise  should  be  in  the  problem  domain  and  not  in  computing.  His/her  primary 
concern  is  the  system  requirements  be  satisfied.  However,  it  is  sometimes  appropriate 
during  a  review  to  assume  the  role  of  instructor.  Balancing  these  dual  roles  is  difficult  and 
sometimes  causes  confusion.  Post-project  student  assessments  indicate  that  when  a  review 
is  not  going  well  that  students  would  like  to  see  more  of  the  instructor  than  the  customer. 


3.5  Team  Status  Reports 

Having  two  reviews  does  not  prevent  a  last  minute  preparation  frenzy  just  before  a  review. 
One  way  to  encourage  regular  directed  activity  is  the  use  of  team  status  reports.  A  team 
status  report  is  submitted  for  each  team  meeting.  It  includes  a  meeting  agenda  related  to 
the  team’s  current  activities.  The  report  indicates  the  disposition  for  each  agenda  item,  the 
members  present  and  absent,  and  the  location  and  time  of  the  meeting. 

The  team  status  report  helps  students  direct  their  own  efforts  and  to  have  more  effective 
meetings.  The  status  of  each  task  is  recorded.  Some  tasks  are  recorded  as  resolved  while 
others  may  be  assigned  to  particular  students  for  resolution  or  for  further  study.  Completing 
the  sum  of  the  tasks  on  the  agenda  moves  the  project  team  closer  to  their  goal.  This 
management  tool  does  not  significantly  increase  the  students'  work  and  enables  the 
instructor  to  monitor  the  progress  of  ail  teams  without  attending  all  team  meetings.  They 
also  help  the  instructor  guide  a  team’s  progress.  The  goal  of  this  process  is  not  to  catch  a 
team  or  team  members  doing  something  wrong,  but  to  guide  a  team  toward  the  successful 
completion  of  its  part  of  the  project. 

One  of  the  hardest  things  in  managing  project  intensive  courses  is  determining  the 
appropriate  degree  of  instructor  management  of  the  project.  While  an  instructor  must  not 
dictate  a  solution,  he/she  must  provide  appropriate  and  timely  direction  and  coaching. 
Steering  of  a  project  takes  several  forms,  from  a  simple  question  like  "Have  you  handled  X 
yet?",  to  attending  a  team  meeting,  or  to  suggesting  an  alternate  solution.  Attending  a  team 
meeting  should  be  done  sparingly  lest  the  students  perceive  this  as  a  "negative  form  of 
monitoring". 
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3.6  inch  Pebbles  Plan 


The  best  management  does  not  always  guarantee  on-time  delivery.  When  a  project 
encounters  difficulty,  the  students  may  want  to  "slip  the  schedule"  by  changing  the  due  dates 
on  the  SPMP.  In  such  instances,  an  inch  pebbles  plan  can  help  students  to  measure  and 
control  their  progress.  An  inch  pebbles  plan  breaks  a  milestone  into  a  series  of  smaller 
tasks  for  reaching  that  milestone.  Such  micro-management  is  only  used  when  absolutely 
necessary.  When  we  have  had  to  resort  to  an  inch  pebbies  plan,  it  has  received  universal 
praise  in  post-project  assessments.  A  sample  inch  pebbles  plan  is  in  Figure  5. 

As  deadlines  near,  even  with  an  inch  pebbles  plan,  a  common  tendency  is  to  resort  to 
undisciplined  development  and  to  ignore  or  relax  configuration  management.  Support  for 
CM  beromes  even  more  important  at  this  point.  Scaling  back  on  the  required  functionality 
of  the  project  is  preferable  to  giving  up  on  CM.  Abandoning  CM  conveys  the  wrong  lessons. 
One  way  to  scale  back  is  to  design  the  inch  pebbles  so  that  the  system  can  be  developed 
incrementally  and  at  any  pebble  a  functioning  system  can  still  be  delivered.  For  example, 
the  plan  in  Figure  5  is  for  a  system  that  passes  source  code  through  a  series  of  tests  or 
filters.  Even  if  the  students  completed  coding  only  one  filter,  they  would  still  produce  a 
working  system  for  an  acceptance  test. 

The  management  techniques  described  above  are  not  difficult  but  require  constant  attention. 
The  return  for  this  investment  is  a  more  mature  development  process.  It  includes  productive 
team  meetings,  effective  coordination  of  different  teams’  efforts,  a  clear  understanding  by 
the  entire  class  of  what  each  team  is  doing,  reduction  in  the  effects  of  procrastination,  and 
a  delivered  software  product. 


4.  Project  Assessment  Techniques 

Feedback  on  the  project  must  be  provided  to  students  throughout  the  course.  Providing 
timely  feedback  can  be  difficult  for  the  instructor,  particularly  in  a  project-oriented  course 
because  of  the  time  demands  associated  with  project  and  team  management.  We 
recommend  multiple  assessment  components.  As  discussed  in  Section  3.4,  properly 
conducted  reviews  are  one  valuable  means  of  accessing  the  product  being  reviewed  and 
the  progress  of  its  development. 

Another  valuable  source  of  feedback  is  the  assessment  of  "first  drafts"  of  deliverables  (e.g., 
user  manual,  requirements  list,  analysis  model).  These  assessments  provide  early 
opportunities  to  steer  teams  in  the  right  direction.  First  drafts  are  reviewed  and  returned  by 
the  next  class  meeting  along  with  a  written  or  oral  critique.  In  either  case,  a  record  is  kept 
and  used  to  assure  that  the  suggestions  and/or  criticisms  are  addressed  in  subsequent 
drafts. 

An  alternative  method  of  providing  quick  feedback  with  minimal  grading  time  is  holistic 
grading.  Holistic  grading,  which  views  an  item  as  an  integrated  whole,  involves  a  penisal 
of  the  entire  item  and  the  assignment  of  a  single  grade  based  on  its  entirety.  Some  student 
work  is  prone  to  holistic  grading;  some  is  not.  For  example,  the  first-level  data  flow  diagram 
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of  a  stnicturad  analysis  modal  might  ba  gradad  hoittioaly  on  lha  foloiaing  0  to  4  acala. 

4  •  (a)  baianoad  with  ooniaxt  diagram; 

(b)  Herns  approprialaly  daacribad  in  data  dteHonary; 

(c)  prooaaaas  appropriida  for  this  iaval; 

(<0  captures  aaaenoe  of  raquM  fUnctionalty; 

(a)  adheres  to  process  and  dida  flow  naming  conventions; 

(f)  adheres  to  notational  standards. 

3  -  Meets  ”4"  description  except  for  Hems  (e)  and  (0.  or  fails  to  meet  one  of  Hems  (a) 
through  (d). 

2  -  Meets  *4*  description  except  for  Hams  (e)  and  (f).  and/or  fails  to  meet  two  of  Hems 
(a)  through  (d). 

1-  Meets  "4"  description  except  for  Hems  (e)  and  (f),and/0r  fails  to  meet  three  of  Hems 
(a)  through  (d). 

0  •  MMts  ”4"  description  except  for  Hems  (e)  and  (f).  and/or  fate  to  meet  any  of  Hems 
(a)  through  (d). 

The  scaie  is  distributed  wHh  the  returned  work  which  is  marked  wHh  a  0, 1 , 2. 3.  or  4.  It  is 
also  made  dear  that  the  instructor  wili  provide  addHionai  explanation  for  the  assessment  if 
asked.  This  rarely  occurs. 

The  detailed  assessment  of  deliverables  assodatsd  wHh  major  milestones  is  also  critical. 
"Product  assessments"  of  deliverables,  induding  the  complete  final  package,  are  conducted. 
For  example.  Figure  6  is  an  excerpt  fr^  the  evaluation  of  a  structured  analysis  model  that 
induded  a  narrative  description  of  the  proposed  system,  a  requirements  list,  context 
diagram,  data  flow  diagrams,  and  data  dictionary. 

Peer  and  self  evaluations  are  used  extensively  in  assessing  individuai  contributions  to  team 
projects.  Students  are  Informed  that  Individuai  project  grades  are  based  on  three  factors: 
team  project  grade  (determined  in  the  produd  assessment),  peer  review,  and  the  instructor’s 
perceptions  of  individual  contributions.  Peer  evaluation  forms  soKcH  student  assessment  of 
the  team’s  products  and  interactiorw  (Figure  7a)  and  of  the  contributions  of  team 
members(Figure  7b).  A  peer  review  is  also  conducM  following  preliminary  design.  WNie 
students  find  peer  review  difficuH.  post-project  assessments  indiMte  that  th^  are  generally 
appreciative  of  the  opportunHy  to  contribute  their  views. 

In  addHion  to  the  integration  of  continuous  assessment  into  aN  project  activHies.  a  dosing 
assessment  has  proven  very  productive.  Often  final  delivery  d  the  course  prpjed  coincides 
wHh  the  final  class  meeting.  This  scheduling  does  not  affonf  time  for  feedback  or  reflection. 
Class  time  should  be  provided  to  appraising  the  strengths  and  weaknesses  of  the  process 
used  and  the  products  developed.  To  focus  students  on  the  assessment  discussions,  they 
are  required  to  complete  an  assessment  instrument.  "Lessons  learned*  dtocussions  resuH 
in  students  foaming  to  be  constructively  critical  of  their  own  work  and  realistic  about  their 
plans.  The  discussions  indude  an  analysis  of  possible  produd  improvements. 


5.  Condusion 
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Atthough  the  inverted  functional  matrix  approach  to  project  intensive  software  engineering 
courses  requires  considerable  effort  from  both  the  instructor  and  the  students,  its  benefits 
are  numerous  and  outweigh  the  difficulties. 

In  this  approach  to  class  project  organization,  students  experience  every  aspect  of  software 
development.  They  are  as^ned  to  teams  throughout  the  life  cycle  and  receive  in-depth 
exposure  to  those  phases  of  the  life  cycle.  Additionally,  through  participation  in  formal 
reviews  and  inter-team  communication,  ttiey  receive  an  understanding  of  tfw  problems  arxi 
tasks  of  the  other  phases  of  the  life  cycle. 

Because  student  success  and  project  success  are  dependent  on  many  forms  of 
communication,  students  learn  to  appreciate  and  practice  these  forms  of  communication. 
A  higher  level  of  precision  is  requir^  in  inter-team  communications  because  teams  which 
must  communicate  directly  with  each  other  have  no  common  students,  informal  speaking 
experience  includes  the  communication  with  ttie  customer  or  user  and  the  intra-feam  and 
inter-team  communications.  Written  skills  are  emphasized  in  the  extensive  documentation 
required  in  this  approach. 

Students,  having  participated  in  the  development  of  significant  deiiverabies,  gain  in-depth 
experience  in  at  least  two  software  development  areas.  Additionally,  they  experience  the 
positive  effects  of  controlling  disciplines  on  the  deveiopment  of  large  projects.  The  inverted 
functional  matrix  organization  is  a  feasible  approach  to  the  organization  of  project-oriented 
software  engineering  courses  and  provides  real-world  project  experience  beyond  that 
available  in  other  project  organizations. 

Copies  of  ail  the  forms  mentioned  are  available  via  electronic  mail  from  the  authors. 
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Real-World  Software  En^r^eering 


V  Example  Ctte 

Below  is  the  project  management  plan  and  the  test  plan  for  an 
extended  student  project.  This  system  examined  two  samples  of 
Pascal  source  code  checking  for  inappropriate  similarities.  We 
have  not  included  either  a  requirements  document  nor  a  design 
document  because  there  are  numerous  satisfactory  examples  of 
them  in  the  literature. 

A.  Configuration  Management 

This  is  a  section  of  the  configuration  management  plan.  The 
material  on  proper  Ada  coding  style  is  not  included  here.  It  is 
chapter  two  of  SPC71 . 


PRCXJECT;  Third  Eye  Project 

FILE  NAME:  CM^PLAN.DCX: 

DOCUMENT  NAME:  Configuration  Management  Plan 


PURPOSE: 

This  document  describes  the  responsibilities  of 
Configuration  Management . 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.2  8/3/93 

*  Added  CM_INCHS.DOC  to  C.M.  files  list 

Kellie  Price  1.1  7/16/93 

*  Added  detailed  design  requirements 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document. 
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Configuration  Managcanent  Plan 


1 .  PURPOSE 

The  Configuration  Managanent  Plan  defines  the  Configuration 
Management  (CM)  policies  which  are  to  be  used  in  the  Third 
Eye  Project.  It  also  defines  the  responsibilities  of  the 
project  configuration  manager. 
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2 .  MANAGEMENT 

2.1  CONFIGURATION  MANAGER  RESPONSIBILITIES 

The  first  responsibility  of  the  configuration  manager 
is  to  develop  and  implement  this  Configuration 
Management  Plan. 

Throughout  the  project,  the  configuration  manager  will 
report  directly  to  the  customer.  It  is  the  configuration 
manager's  responsibility  to  ensure  that  the  project  is 
implemented  in  a  straight-forward  and  well-defined  manner 
according  to  the  customer's  specifications  and  standards 
established  by  Configuration  Management  for  this  project. 

2 . 2  ORGANIZATION 

This  project  will  be  divided  into  7  teams  as  follows: 
(Refer  to  CM_TEAMS.DOC  for  the  specific  team  assignments) 

NOTE;  All  of  the  documents  required  of  each  team  below 
are  listed  in  the  file  CM^DOCS.DOC. 

2.2.1  REQUIREMENTS  TEAM 

The  Requirements  Team  is  responsible  for 
^communicating  with  the  customer  in  order  to 
determine  and  well-define  the  software  system 
requirements.  The  documents  required  of  the 
Requirements  Team  are: 

*  Narrative  description  of  system 

*  List  of  requirements  (acceptance  criteria) 

*  Context  Diagram 

*  A  series  of  leveled  Data  Flow  Diagrams 

*  Data  Dictionary 

*  Process  Specifications 


2.2.2  USER  MANUAL  TEAM 

The  User  Manual  team  is  responsible  for 
producing  all  user  documentation  for  the 
system.  The  documents  required  of  the  User 
Manual  Team  are: 

*  Preliminary  format  of  user  manual 

*  User  Manual 
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2.2.3  TEST  PLAN  TEAM 

The  Test  Plan  team  is  responsible  for 
designing  subsystem  and  system  tests.  The 
documents  required  of  the  Test  Plan  Team  are: 

*  Test  plan 


2.2.4  PRELIMINARY  DESIGN  TEAM 

The  Preliminary  Design  team  is  responsible  for 
creating  a  preliminary  design  structure  of  the 
system  based  on  the  software  system 
requirements.  The  docviments  required  of  the 
Preliminary  Design  Team  are: 

*  An  Object  Model: 

*  Complete  object  diagram 

*  Class  dictionary 

*  Object-Requirements  traceability  matrix 

*  Ada  Specifications  for  each  object  class 


2.2.5  DETAILED  DESIGN  TEAM 

This  team  is  responsible  for  creating 
algorithms  to  implement  the  system  structure. 
The  doc\aments  required  of  the  Detailed  Design 
Team  are: 

*  Data  Structure  design 

*  Algorithm  design 

*  Traceability  Matrix 


2.2.6  CODE  &  UNIT  TEST  TEAM 

The  Code  &  Unit  Test  team  is  responsible  for 
producing  source  code  for  the  algorithms 
produced  by  the  Detailed  Design  Team,  testing 
each  module  of  the  system  separately,  and 
integration  of  the  modules  to  produce  a 
working  system.  The  documents  required  of  the 
Code  &  Unit  Test  Team  are: 

*  Source  code 
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2.2.7  TESTING  TEAM 

The  Testing  team  is  responsible  for 
implementing  the  tests  in  the  test  plan  and 
using  them  to  test  the  system.  The  documents 
required  of  the  Testing  Team  are: 

*  Test  data 

*  Documented  test  results 
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3.  CONFIGURATION  MANAGEMENT  ACTIVITIES 


3.1  C.M.  REQUIREMENTS  DOCUMENTS 


The  configuration  manager  has  provided  documentation  to 
assist  the  teams  in  meeting  the  C.M.  re<^irements .  This 
documentation  is  in  a  series  of  files  which  are  available 
on  the  project  file  server.  The  C.M.  requirements 
defined  in  these  files  are  as  follows: 


DESCRIPTION 


FILENAME 


*  Documents  required  by  C.M. 

*  Document  header  info 

*  Docvunent  naming  conventions 

*  Document  format  &  standards 

*  Change  request  form  format 

*  Configuration  item  request  procedure 

*  Configuration  item  access  procedure 

*  Configuration  item  change  process 

*  Configuration  item  baseline  process 


CM_DOCS.DOC 

CM^HEADR.DOC 

CM_NAMES.DOC 

CM_FORMT.DOC 

CM_CHREQ.DOC 

CM_CIREQ.DOC 

CM_ACESS.DOC 

CM_CHPRO.DOC 

CM_BASLN.DOC 


3.2  C.M.  CONTROL 

The  configuration  m5uiager  will  provide  the  teams  euid  team 
members  controlled  access  to  their  respective 
configuration  items.  In  order  to  have  access,  however, 
the  teams  and/or  team  members  must  provide  the 
configuration  manager  with  a  written  request  for  any 
desired  configuration  items  as  defined  in  the  file 
CM_CIREQ.DOC. 
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4.  CONFIGURATION  MANAGEMENT  RECORDS 

All  BASELINED  Configuration  Items  and  docxanents  will  be 
maintained  on  the  project  file  server  in  a  directory  structure 
as  defined  in  the  file  CK_FILES.DOC. 


4.1  C.M.  FILES 

All  Configuration  Management  files  (including  the 
requirements  files  listed  in  section  3.1)  are  listed 
below: 


DESCRIPTION 


FILENAME 


*  Configuration  item  access  procedure 

*  Configuration  item  baseline  process 

*  Configuration  item  change  process 

*  Change  request  form  format 

*  Configuration  item  request  procedure 

*  Original  customer  request 

*  Doctiments  required  by  C.M. 

*  C.M.  file  directory  structure 

*  Change  request  form 

*  Document  format  &  standards 

*  Document  header  info 

*  Project  Inch  Pebbles 

*  Document  naming  conventions 

*  Document  page  header 

*  Configuration  Management  Plan 

*  Software  Project  Management  Plan 

*  Project  team  organization 


CM_ACESS.DOC 

CM_BASLN.DOC 

CM_CHPRO.DOC 

CM_CHREQ.DOC 

CM_CIREQ.DOC 

CMLCRQST.DOC 

CM_DOCS.DOC 

CM_FILES . DOC 

CM_FORM.DOC 

CM_FORMT.DOC 

CK-HEADR.DOC 

CH-INCHS.DOC 

CM_NAMES.DOC 

CM_PGHDR.DOC 

CM_PLAN.DOC 

CM_SPMP.DOC 

CM  TEAMS . DOC 
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PROJECT:  Third  Eye  Project 

FILE  NAME:  CH-CRQST.OOC 

DOCUMENT  NAME:  Custc^ner  Request 


PURPOSE: 

This  document  is  the  actual  customer  request  for  the 
software  systan 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Dr.  Riser (customer)  1.0  6/22/93 

*  Created  initial  revision  of  document 


CSCI-4910  SOFTWARE  SYSTEMS  DEVELOPMENT  WORKSHOP 
SUMMER  1993  -  GOTTERBARN/RISER/SMITH 

PROJECT  2  -  CUSTOMER  REQUEST 


As  Dean,  I  often  have  to  make  the  final  decision,  or  make 
recommendations  to  a  university  hearing  committee,  in  academic 
misconduct  cases  involving  suspected  plagiarism  of  student 
programs  in  computer  science  courses.  I  would  like  a  system 
that  can  compare  student  programs  and  determine,  with  a  high 
degree  of  credibility,  whether  plagiarism  has  occurred.  I 
need  an  analysis  report  that  is  clear  and  understandable  and 
could  be  presented  as  evidence  to  a  university  hearing 
committee. 

The  program  will  be  used  by  faculty  to  screen  student  programs 
for  possible  plagiarism  euid  to  provide  an  objective  analysis 
to  support  or  negate  their  subjective  opinions. 
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PROJECT:  Third  Eye  Project 

FILE  NAME:  CH.SPMP.DOC 

DOCUMENT  NAME:  Software  Project  Management  Plan 


PURPOSE: 

This  document  defines  the  plan  to  be  followed  during 
the  production  of  this  system. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Gotterbarn/Riser/Smith  1.0  6/22/93 

*  Created  initial  version  of  this  docxunent 
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JQatfi 

6/22 

6/28 

6/29 

7/6 

7/6 

7/8 

7/8 

7/12 

7/13 

7/19 

7/20 


7/26 

7/27 

8/6 

8/9 

8/10 

Items 
All  Cl 


Kamag 

Software  Project  Hanegeswnt  Plan 
Extended  Project  Susner  1993 

Cl  Id  DascripUoB 

Customer  Request  presented. 

Team  assignments  announced  and  roles  defined. 

Start  Development  of  Configuration  Management 
Plan (CMP),  Preliminary  Requirements ( P_RBQ) , 
Preliminary  Test  Plam(P_TP),  and  Preliminary 
User's  Manual  (PJUM) . 

CI-1  CMP  delivered  and  presented  to  teams. 

CI-2  P_REQ  delivered  and  presented  to  teams  and 

customers . 

CI-3  P_TP  delivered  and  presented  to  teams. 

CI>4  P_UM  delivered  and  presented  to  teams. 

Requirements  review.  Preliminary  design 
begins. 

CI-5  Pinal  revised  requirements  is  delivered  amd 

baselined  by  CM. 

Preliminary  design  review. 

CI-6  Final  Preliminary  Design  is  delivered  and 

baselined  by  CM. 

CI-7  Final  test  plan  is  delivered  and  baselined  by 

CM. 

CI-8  Final  User  Manual  is  delivered  and  baselined 

by  CM. 

Detailed  Design  Review. 

CI-9  Detailed  design  delivered  amd  baselined  by  CM. 

Completed  code  goes  to  integration  testing 

Cl -10  Source  and  Object  Code  Delivered. 

System  acceptance  test  is  conducted  amd  the 
complete  system  amd  all  associated  documents 
are  delivered  to  the  customer, 
in  bold  denote  student  presentations. 

's  are  due  at  the  beginning  of  class  on  the  specified  dates! 
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PROJECT:  Third  Bye  Projact 

FILE  NAME:  CH_INCHS.DOC 

DOCUMENT  NAME:  Third  Eye  Project  Inch  Pebbles 


PURPOSE: 

This  document  divides  the  r«tialning  project  'milestones' 
into  'inch-pebbles'  so  that  the  deadlines  will  be  easier 
met  and  progress  may  be  made  on  several  different  teams  at 
the  same  time. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Gotterbarn/Riser  1.0  7/29/93 
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Date 
4:00  PM 
7/30 


7/30- 

8/2 


INCH  PEBBLES,  July  29-August  10th 
TESTING  CQPINg  DETAILED  DESIGN 

Nassi-S  Charts, 
Data  Structure 
Dictionary  to  CM, 

TEST,  CODE 


Develop  Tests 
for  FILE,  DRIVER 
SUMMARY  REPORT, 
FILTER  1 


Write  FILE,  DRIVER 
SUMMARY  REPORT, 
MENU,  FILTER  1, 
SOURCEPROGRAM-Fl 


Develop  trace 
matrix,  help 
screens.  Summary 
Report  Format 


8/2 


Run  tests  on 
delivered  code 
and  Build  tests 
for  FILTER2 


Deliver  7/30  unit 
tested  code  to  CM, 
and  TEST. 

Code  all  FILTER2 
applications 


Deliver  7/30 
items  to  CM,  CODE 
and  TEST 


8/3 


8/4 


8/5 


8/6 


8/9 


Discrepancy  report 
on  8/2  tests  to  CM 
Write  test  for 
FILTERS  3  and  4 


Deliver  FILTER  2  CODE 
to  CM  and  TEST 
Write  code  for  FILTER  3 
and  FILTER  4.  Respond  to 
discrepancy  reports. 


Discrep€mcy  report 
on  8/3  tests  to  CM 
Write  tests  for 
FILTERS  5  &  6  and 
Help  screens. 


Deliver  FILTERS  3  &  4  to  CM 
and  TEST.  Write  code  for 
FILTERS  5  &  6.  Write  Help  screens. 
Respond  to  discrepancy  reports. 


Discrepeuicy  report 
on  8/4  tests  to  CM 
Write  tests  for 
FILTERS  7. 


Deliver  FILTERS  5  &  6  to  CM 
and  TEST.  Write  code  for 
FILTERS  7. 

Respond  to  discrepancy  reports. 


Discrepancy  report 
on  8/5  tests  to  CM 
Write  tests  for 
FILTER  8. 


Deliver  FILTERS  7  to  CM 
euid  TEST.  Write  code  for 
FILTERS  8. 

Respond  to  discrepancy  reports. 


Discrepeuicy  report 
on  8/6  tests  to  CM 
Write  accept. test 


Deliver  FILTERS  8  to  CM  and 

and  TEST.  Respond  to  discrepancy 

reports. 


8/10  Conduct  acceptamce  test. 

All  test  data  to  CM 


NOTES:  Deliverables  are  in  bold  and  both  electronic  &  hard  copies 

are  provided.  All  delivered  code  is  to  be  unit  tested. 
Discrepancy  reports  (DRs)  are  the  results  of  testing  by  test 
team  on  baselined  code.  The  CM  passes  DRs  to  CODE.  When  DR 
is  fixed,  a  CR  and  modified  code  is  given  to  CM.  CM 
baselines  new  code  and  delivers  it  to  testing. 
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I  PROJECT:  Third  Eye  Project 

I  FILE  NAME:  CH_FILES.DOC 

I  DOCUMENT  NAME:  C.M.  File  Directory  Stzxicture 


I  PURPOSE: 

I  This  document  defines  file  directory  structure  which  I 

will  be  used  by  configuration  management  to  file  I 
configuration  items. 


N(M>IFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.1  8/9/93 

*  Added  Detail  and  Prelim  subdirectories 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


The  file  directory  structure  is  as  follows: 


GROUPS  -->  CFGMGMT - + - >  DOCUMENT  -+ - >MGMTDOCS 

I  + - >  REQMENTS 

I  +  — ->  DESIGN  -+— >  PRELIM 

I  +— >  DETAIL 

I  +— >  TESTDOCS 

I  +  — ->  USERMNUL 

+---->  SOURCECD 
+ - >  TESTDATA 
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PROJECT;  Third  Eye  Project 

FILE  NAME:  CM_ACESS.DOC 

DOCUMENT  NAME:  Configuration  Item  Access  Procedure 


PURPOSE: 

This  document  describes  the  procedure  to  be  followed 
when  accessing  a  configuration  item. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


In  order  to  access  the  configuration  items  under  configuration 
management  control,  the  following  steps  may  be  taken: 

NOTE:  The  project  files  are  located  on  the  network  which  can  be 

accessed  in  Gilbreath  Lab  105. 

NOTE:  The  project  files  are  available  for  READ  access  ONLY. 

1.  Pull  up  the  main  menu  on  the  network 

2.  Press  the  'ESCAPE'  key 

3.  You  should  now  be  at  the  U:\>  prompt 

4.  IVpe  LOGIN  CSCISERV/SECMUSER  at  the  U:\>  prompt 

5.  Enter  your  password.  The  password  is  CMUSER. 

6.  You  will  now  be  at  the  F:\>  prompt 

7.  Type  CD  GROUPS \CFGMGMT  at  the  F:\>  prompt 

8.  You  are  now  in  the  CFGMGMT  directory. 

9.  Type  DIR  for  a  list  of  the  subdirectories. 

10.  Choose  the  subdirectory  you  wish  to  access. 

11.  When  you  are  finished,  you  MUST  LOGOUT!  To  logout  you 
must : 

— >  Type  CD\  (return  to  the  F:\>  prompt) 

-->  Type  CD  LOGIN 
— >  Type  LOGOUT 

PLEASE,  DO  NOT  FORGET  TO  LOGOUT! ! ! ! ! ! 
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PROJECT:  Third  Eye  Project 

FILE  NAME:  CMLDOCS.DOC 

DOCUMENT  NAME:  Configuration  Management  Items 


PURPOSE: 

This  document  defines  the  documents  that  will  be  placed 
under  configuration  management  control. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.1  7/16/93 

*  Added  Detailed  Design  documents 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


The  following  documents  will  be  placed  under  configuration  manag^ent 
control : 

Requirements  Documents: 

*  Narrative  description  of  system 

*  List  of  requirements  (acceptance  criteria) 

*  Context  diagram 

*  A  series  of  leveled  Data  Flow  Diagrams 

*  Data  Dictionary 

*  Process  specifications 

User  Manual  Documents: 

*  Preliminary  format 

*  User  Manual 

Test  Plan  Doc’oments: 

*  Test  plan 

Preliminary  Design  Documents: 

*  Object  Model: 

*  Complete  object  diagram 

*  Class  dictionary 

*  Object -Requirements  traceability  matrix 

*  Ada  specifications  for  each  object  class 

Detailed  Design  Docxjunents: 

*  Data  Structure  design 

*  Algorithm  design 

*  Traceability  Matrix 

Code  Documents: 

*  Source  code 


Testing  Documents; 

*  Test  data 

*  Documented  test  results 
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PROJECT:  Third  E^e  Project 

FILE  NAME:  CM_HEADR.DOC 

DOCUMENT  NAME:  Document  Header  Definition 


PURPOSE: 

This  docijment  defines  the  document  header  that  will  be 
at  the  top  of  all  documents  placed  under  configuration 
management  control. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


The  format  for  the  header  is  as  follows: 

NOTE:  The  text  enclosed  in  '<  >'  must  be  x'eplaced  with  the 

appropriate  information  by  the  docviment  author. 


1 

PROJECT: 

<project  name  here> 

1 

FILE  NAME: 

<file  name  here . 

.defined 

in  CM_NAMES . DOC> 

1 

DOCUMENT  NAME: 

<document  name  here . . 

(document 

description) > 

1 

PURPOSE: 

1 

<purpose 

of  this  document > 

1 

MODIFICATION  HISTORY: 

1 

WHO; 

REV: 

DATE: 

1 

<person ' s 

name>  <new  rev.#> 

<date 

revised> 

1 

1 

*  <description  of  modification  made> 

1 

1 

<person' s 

name>  1 . 0 

<initial  date> 

1 

*  Created  initial  revision  of 

document 
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PROJECT:  Third  Eye  Project 

FILE  NAME:  CM_NAMES.DOC 

DOCUMENT  NAME:  Configuration  Item  Naming  Conventions 


PURPOSE: 

This  document  defines  the  naming  conventions  to  be  used 
for  all  items  placed  under  configuration  management 
control . 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.2  8/2/93 

*  Added  .PMD  extension  for  PMDRAW  files 

Kellie  Price  1.1  7/22/93 

*  Added  .OMT  extension  for  OMTOOL  files 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


valid  file 

name  prefixes  are  as  follows: 

Prefix 

Team  name 

CM_ 

Configuration  Manager 

RQ_ 

Requirements  Team 

UM_ 

User  Manual  Team 

TP_ 

Test  Plan  Team 

PD_ 

Preliminary  Design  Team 

DD_ 

Detailed  Design  Team 

sc_ 

Coding  Team  (Source  Code) 

TD_ 

Testing  Team  (Test  Data) 

TR_ 

Testing  Team  (Test  Results) 

The  remaining  5  characters  are  entirely  up  to  the  documents 
author.  It  is  his/her  responsibility  to  ensure  that  names 
are  not  duplicated  within  a  team. 

The  valid  file  extensions  are  as  follows: 


Extension 

Type 

.DOC 

WordPerfect  file 

.TST 

System  test  file 

.DFD 

Case  tool  files  (all  leveled 

DFD ■ S ) 

•  DBF 

Case  tool  file  (Data  dictionary) 

.NDX 

Case  tool  file  (Data  diet,  index) 

.OMT 

Case  tool  file  (OMTOOL) 

.PMD 

Case  tool  file  (PMDRAW) 

.ADA 

Main  program  (driver)  source 

file 

.ADS 

Package  specification  source 

file 

.ADB 

Package  body  source  file 

NOTE:  The  case  tool  files  will  have  no  prefix  due  to  the  fact 
that  the  case  tools  name  the  files  automatically. 
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PROJECT:  Third  Eye  Project 

FILE  NAME:  CM_FORMT.DOC 

DOCUMENT  NAME:  Dociiinent  Format  &  Stemdards 


PURPOSE: 

This  document  defines  the  docximent  format  stwdards 


MODIFICATION  HISTORY: 

MHO:  REV:  DATE: 

Kellie  Price  1.1  7/16/93 

*  Added  detailed  design  notation. 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  doctiment 


1 .  GENERAL  INFORMATION 

1 . 1  MEDIA 

All  documents  (files)  will  be  submitted  to  configuration 
management  as  WordPerfect  files  (with  the  exception  of 
source  code,  test  data,  and  case  tool  files)  on  a  3.5" 
dislcette. 

1 . 2  NAMING 

All  docximents  (files)  will  follow  the  naming  conventions 
defined  in  CM_NAMES.DOC. 

1 . 3  VERSIONS 

All  versions  of  documents  will  laegin  at  1.0.  Subsequent 
versions  will  be  assigned  a  number  of  l.X,  where  X  is  the 
next  sequential  number.  The  version  number  is  not 
changed  until  the  document  has  been  baselined  and  a 
significant  change  has  been  requested,  approved,  and 
made. 

1 . 4  HEADERS 

All  documents  will  contain  a  dociiment  header  ds  defined 
in  CM_HEADR,DOC. 

2 .  STYLE 

2 . 1  DOCUMENTS 

All  documents  should  adhere  to  the  document  standards 
presented  in  class. 

2 . 2  SOURCE  CODE 

All  source  code  should  adhere  to  the  coding  standards 
of  Ada  which  can  be  found  in  the  Appendix  of  the 
Configuration  Management  Plan. 

2 . 3  PRELIMINARY  DESIGN 

The  Object  Model  will  consist  of: 

1)  A  complete  object  diagram  using  Rumbaugh 
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notation  as  presented  in  class, 

2)  A  class  dictionary  entry  using  notation 
presented  in  class, 

3)  An  Object-Requirements  traceability  matrix 
using  notation  presented  in  class.  Ada 
specifications  should  adhere  to  the  coding 
standards  of  Ada  which  can  be  found  in  the 
Appendix  of  the  Configuration  Management  Plan. 

2 . 4  DETAILED  DESIGN 

The  Data  Structure  Design  will  consist  of  a  Data 
dictionary  with  both  object  entries  and  attribute 
entries . 

The  Algorithm  design  will  consist  of  Nassi-Shneiderman 
models  for  each  operation.  The  traceability  matrix  will 
be  made  up  of  two  things:  1)  Data  Structures  are  related 
to  Ob ject_At tribute,  and  2)  NS-Models  are  related  to 
Object_Operations.  The  specific  notation  for  these 
documents  are  according  to  that  which  was  presented  in 
class. 

3 .  FORMAT 

The  following  sections  describe  a  format  which  will  be  used 
for  all  appropriate  configuration  items  (such  as  the  User 
Manual  and  the  Test  Plan) .  Reference  should  be  made  to  the 
Configuration  Management  Plan  as  an  example  of  this  format. 

3 . 1  TITLE  PAGE 

All  documents  will  have  a  title  page  which  will 
include  the  following: 

*  Project  name 

*  Document  name 

*  Team  (or  author’s)  name 

3.2  TABLE  OF  CONTENTS 

All  documents  will  have  a  table  of  contents  which  will 
loolc  lilce  the  following: 


Table  Of  Contents 


1.  MAJOR  IDEA . 1 

1.1  SUPPORTING  IDEA . 1 

1.2  SUPPORTING  IDEA . 2 

2  .  MAJOR  IDEA . 3 

2 . 1  SUPPORTING  IDEA . 4 

2.2  SUPPORTING  IDEA . 4 

2.2.1  SUPPORTING  IDEA . 5 


3.3  PAGE  HEADER 

All  documents  will  have  a  page  header  on  each  page  of 
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text  (not  including  Title  page,  Table  of  Contents,  Index, 
or  Appendix)  which  will  include  the  document  name  and  the 
page  number.  It  is  available  in  the  file  CM_PGHDR . DOC . 
(Refer  to  CM_ACESS.DOC  for  details  in  accessing  the 
document.)  It's  format  is  similar  to  the  following: 

Document  Name  1 


3.4  SECTION  NUMBERING  AND  HEADERS 

All  documents  will  have  the  same  numbering  scheme.  This 
numbering  scheme  is  liJce  that  in  the  Table  of  Contents 
example  above.  Section  headers  will  be  ALL  CAPS  and 
indented  as  in  the  example  also. 

3.5  INDEX, APPENDIX 

All  docxoments  are  not  required  to  have  an  Index  or  an 
^pendix,  but  these  are  optional  and  should  be  used  when 
appropriate. 

3 . 6  FONT , JUSTIFICATION 

All  documents  should  use  the  default  fonts  and 
justification  values  of  WordPerfect  5.1. 
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PROJECT:  Third  Eye  Project 

FILE  NAME:  CM_CHREQ.DOC 

DOCUMENT  NAME:  Change  Request  Form  Definition 


PURPOSE: 

This  document  defines  the  format  for  the  change  request 
form. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


CHANGE  REQUEST  FORM 


Date: 

Project : 

Configuration  Item  to  be  changed: 
Change  requestor; 

Requested  change: 

Improvement  or  repair: 


Change  request  #; 

Review  date; 

Reviewer: 

Affected  components; 
Requirements  Modification?: 
Priority: 

Estimated  time: 

Will  be  implemented?; 
Change  description: 
Comments: 


SIGN  OFF  LIST 


Change  implementor: 
Configuration  Manager; 
Customer : 
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Date: 
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PROJECT;  Third  Eye  Project 

FILE  NAME;  CM_CHPRO.DOC 

DOCUMENT  NAME;  Configuration  Item  Change  Process 


PURPOSE; 

This  doctunent  describes  the  process  to  be  followed  when 
changing  a  configuration  item. 


MODIFICATION  HISTORY; 

WHO;  REV;  DATE; 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


1.  When  a  change  to  the  system  or  a  configuration  item  is 
desired,  a  change  request  form  must  be  submitted  to  the 
configuration  manager. 

1.1  The  change  request  form  will  be  available  in  the  file 
CM_FORM.DOC  .Refer  to  CM_ACESS.DOC  for  details  in 
accessing  the  documents. 

1.2  Th'‘  change  request  form  must  follow  the  format 

described  in  the  file  CM_CHREQ.DOC. 

1.3  The  change  request  form  must  be  filled  out  as 

completely  as  possible  by  the  person  requesting  the 
change . 

2.  The  change  request  is  reviewed  by  the  configuration  manager 
and  appropriate  project  team  members. 

2.1  A  decision  will  be  made  as  to  whether  or  not  the  cheuige 
is  necessary  and/or  feasible.  Requests  in  by  4  P.M. 
will  be  returned  by  10  A.M.  the  following  day. 

3.  The  change  is  made  and  reviewed  by  the  configuration  manager 
and  appropriate  team  members. 

4.  If  the  change  modifies  any  customer  requirements,  the 
customer  must  also  agree  to  it. 

5.  The  change  request  form  must  be  signed  by  the  appropriate 
project  team  members. 
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PROJECT:  Third  Eye  Project 

FILE  NAME:  CM_CIREQ.DOC 

DOCUMENT  NAME:  Configuration  Item  Request  Process 


PURPOSE: 

This  document  describee  the  process  to  be  followed  when 
requesting  a  configuration  item  from  configuration 
management  for  modification. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


1.  A  written  request  is  made  to  the  configuration  manager  in 
the  form  of  an  approved  change  request.  The  request  should 
include  the  following: 

1.1  The  name(s)  of  the  desired  file(s)  and  the  change 
request  form  number (s)  if  applicable. 

1.2  The  name  of  the  person  responsible  to  see  that  the 
modified  docxjunent  (s)  is  re-submitted  to  the 
configuration  manager. 

1.3  A  BLANK  FORMATTED  3.5"  diskette. 

1.4  Any  additional  information  the  configuration  meuiager 
may  need. 

NOTE:  Once  a  baselined  configuration  item  has  been  checked  out, 

it  will  be  locked  and  will  not  be  available  for 
additional  changes  until  the  updated  version  has  been 
re-sulmiitted  and  approved. 
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PROJECT;  Third  Eya  Project 

FILE  NAME:  CH.BASLM.DOC 

DOCUMENT  NAME:  Baseline  Process  Description 


PURPOSE: 

This  document  describes  the  process  which  will  take 
place  when  a  configuration  item  is  baselined. 


MODIFICATION  HISTORY: 

WHO:  REV:  DATE: 

Kellie  Price  1.0  7/12/93 

*  Created  initial  revision  of  document 


When  a  baseline  or  release  is  to  be  made,  the  following  steps 
must  be  performed: 

1.  All  appropriate  configuration  items  will  be  submitted. 
The  following  conditions  are  required  of  each  document: 

1.1  The  document  must  be  one  of  the  documents  listed 
in  the  file  CH_DOCS.DOC. 

1.2  The  document  must  represent  the  most  up-to-date 
version  in  the  configuration  management  files. 

2.  In  the  event  that  a  baselined  Configuration  Item  is 
changed,  the  Configuration  Manager  will  notify  the 
customer,  if  necessary,  and  each  project  team.  Any 
necessary  explanations  will  be  provided  at  that  time 
regarding  the  nature  of  the  change. 
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TEST  PLAN 


This  »  part  of  the  test  plan  for  the  plagarism  project.  The  system  did  multiple  comparisons 
on  two  Pascal  programs.  Each  type  of  comparison  was  called  a  FILTER.  There  is  a 
complete  set  of  test  documentation  f^  a  filter,  but  since  the  documents  are  similar  for  each 
filter,  not  every  test  is  included. 


PROJECT:  Third  Eye  Project 

FILE  NAME:  TP_TSTPL.DOC 

DOCUMENT  NAME:  Test  Plan 


PURPOSE; 

This  document  describes  the  testing  strategy  for  the 
Third  Eye  Project. 


MODIFICATION  HISTORY; 

WHO;  REV:  DATE: 

Woodrow  Beverley  1.2  8/08/93 

*  Changed  expected  results  for  name  too  long  in 

*  test  A3  from  rejected  to  truncated.  Also 

*  corrected  the  input  data  in  these  cases  to 

*  exceed  32  characters.  Added  new  case  of  (file 

*  already  exists)  to  test  A3. 

* 

*  Changed  test  case  of  CONST  type  of  FILE  to  SET. 

♦ 

*  Corrected  test  data  required  section  in  tests 

*  B2b  and  B2c. 

* 

*  Corrected  test  header  in  B2d. 

WHO;  REV;  DATE; 

Woodrow  Beverley  1.1  8/03/93 

*  1)  Changed  all  filter  percentage  test  to  have  a 

*  tolerance  of  +  or  -  4% 

*  2)  Deleted  the  expected  physical  line  count  and 

*  Pascal  line  count  from  all  test  matrices. 

*  3)  Added  Pascal  line  count  and  physical  line 

data  for  filter  one. 

WHO:  REV:  DATE: 

Woodrow  Beverley  1.0  7/28/93 

*  Created  initial  revision  of  document 


Computer  emd  Information  Sciences 
Third  E^e  Project 

Test  Pl2m 


Woodrow  Beverley 
Mitch  Moses 
Drew  Picklesimer 
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1. 


INTRODUCTION 


The  Test  Plan  is  presented  in  sections  3  and  4  of  this 
document.  Section  3  describes  the  methods  to  be  used  for  the 
testing  process.  Section  4  contains  the  test  procedures  to  be 
executed.  These  procedures  are  derived  from  the  requirements 
specification  document  for  the  Third  Plagiarism  Detection 
System.  Blank  copies  of  the  forms  presented  in  section  3  will 
be  included  in  the  Appendix. 

2.  REFERENCED  DOCUMENTS 

Client  Request  Version  1.0. 

Configuration  Management  Plan  Version  1.0. 

Process  Specifications  Version  1.0. 

Project  Narrative  Version  1.0. 

Requirements  Specification  Version  1.0. 

3.  TEST  METHODOLOGY 

The  following  paragraphs  will  describe  the  items  to  be 
considered  in  the  planning  of  the  tests  for  the  Third  Eye 
Plagiarism  Detection  System. 

3.1  TEST  GROUP  INVOLVEMENT 

The  Test  Group  will  perform  the  integration  tests,  report 
any  test  failures  to  the  Code  Team,  and  ensure  that  all 
problems  have  been  fixed  at  the  end  of  the  project.  Also, 
the  Test  Group  will  be  responsible  for  demonstrating  the 
acceptance  test  to  the  customer. 

3 . 2  REQUIREMENTS  TRACEABILITY 

The  methodology  for  showing  traceability  of  the 
requirements  to  the  tests  will  be  accomplished  through  a 
Test /Requirements  Traceability  Matrix  shown  on  the 
following  page.  Each  requirement  will  be  represented  in 
the  matrix  by  its  number  in  the  requirements  list.  Each 
requirement  will  then  be  matched  with  a  test  or  group  of 
tests  from  the  integration  test  list  (see  section  3.4). 

The  methods  for  verifying  the  requirements  are  as  follows: 


1)  test  and  analysis  of  test  results  and 

2)  demonstration  of  the  system. 


Test/Requirements  Testability  Matrix 


Requirement  # 
Functional 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 


36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 


Tests 

A1 

A1 

Bla  -  B8d,  F 
A2,  Bla  -  B8d 
D 
D 

Bla  -  B8d 
Bla  -  B8d 

Blc , B2f , B3b, B4c , B5f , B6b, B7c , B8c , E 

A3 

A3 

A3 

A3 

A3 

A3 

A3 

A3 

Bla  -  B8d 

Bla  -  B8d,  E 

Bib 

Bla 

Bla 

Bib 

Bla 

Bla 

Bla  -  Bid 

Blc 

B2e 

B2a 

B2b 

B2d 

B2c 

B2a  -  B2g 
B2£ 

B3a  -  B3c 
B3a  -  B3c 
B3b 

B4a  -  B5g 
B4a  -  B5g 
B4d,  B5g 
B4b 
B4a 
B4a 

B4a  -  B4d 
B4b,  B5a 
B4c 


Tsstisl 


Functional 


47 

B5a 

-  B5g 

48 

B5a 

49 

B5b 

50 

B5d 

51 

B5c 

52 

B5a 

-  B5g 

53 

B5a, 

B6a 

54 

B5£ 

55 

B6a 

56 

B6b 

57 

B7a, 

B7d 

58 

B7b, 

B7d 

59 

B7a 

-  B7d 

60 

B7c 

61 

B8a 

-  B8d 

62 

B8a 

-  B8d 

63 

B8c 

Non- functional 

3 

C 

3.3  TEST  SCHEDULE 


The  planning  schedule  shown  below  outlines  the  plan  for 
completing  the  Test  Plan,  developing  procedures,  and  test 
execution. 

Test  Schedule 


June  28 

July  20 

Complete  Test 
Plan 

July  6 

July  20 

Develop 

Procedures 

July  26 

August  5 

Generate  Test 
Data 

August  6 

August  10 

Complete  Test 
/  Bug  Fix 
Cycles 

3.4  TESTS  TO  BE  PERFORMED 


The  test  list  shovm  below  shows  test  categories,  any  successful 
prerequisites  needed  by  the  test  and  the  order  in  which  the  tests 
will  be  executed. 


Tests  to  be  Performed 


A.  Prompts 

1.  Pascal  source  programs 

2 .  Exit  Test 

3.  Report  Information 

*  Report  name 

*  Course  name 

*  Professor's  name 

*  Students '  neimes 


B.  Filters 

1.  Filter  1 

a.  Physical  lines  /  comments  3 

b.  Constructs  5 

*  Assignments 

*  Procedure  calls 

*  Simple  IF  statements 

*  Compound  IF  statements 

*  Simple  IF  /  ELSE  statements 

*  Compound  If  /  ELSE  statements 

*  CASE  statements 

*  REPEAT  UNTIL  statements 

*  WHILE  statements 

*  FOR  statements 

c .  Percentage  6 

*  Two  identical  programs  100% 

*  79%  test 

*  80%  test 

*  10%  test 

d.  Torture  7 

*  Comments  and  code  on  same  line 

*  All  code  commented  out 

*  Comment  syntax  in  literal  string 

*  Pascal  declarations 


A1 

Bla 


A1 


A1 


A1 


r 


Order  of 

Integration  Tests  TfiStfi - 

2.  Filter  2 

a.  Global  VARiable  declarations  8 

*  Array  types 

*  Boolean  types 

*  Char  types 

*  File  types 

*  Integer  types 

*  Real  types 

*  String  types 

*  User  defined  types 

b.  Global  CONSTant  declarations  9 

*  Array  types 

*  Boolean  types 

*  Char  types 

*  File  types 

*  Integer  types 

*  Real  types 

*  String  types 

*  User  defined  types 

c.  Global  TYPE  declarations  10 

*  Record  types 

*  User  defined 

d.  Global  function /Procedure  declarations  11 

e.  Total  number  of  global  declarations  12 

f.  Percentage  13 

*  Two  identical  programs  100% 

*  79%  test 

*  80%  test 

*  10%  test 

*  0%  test 

g.  Torture  14 

*  Comments  and  code  on  same  line 

*  All  code  commented  out 

*  Multiple  variables  separated 
by  commas 

*  Functions  declared  in  procedures 

*  Procedures  declared  in  procedures 


Successful 

Pnerfiguisite 

B1 


Order  of 


Successful 


Integration  Testa 


ISa.ta-..,  -  Prerequisite 


3 .  Filter  3 

a.  Function /Procedure  interfaces  15 

*  Functions  (Same  number  of  parameters, 
same  types,  same  order) 

*  Procedures  (Same  number  of  parameters, 
same  types,  same  order) 

*  Mix  of  Functions /Procedures 

*  Same  number  of  parameters  different 
types 

*  Seune  number  of  parameters  same  type 
different  order 

*  Same  number  of  parameters  same  type 
different  pareuneters  VARed 

b.  Percentage  16 

*  Two  identical  programs  100% 

*  79%  test 

*  80%  test 

*  10%  test 

*  0%  test 

c.  Torture  17 

*  Functions  in  procedures 

*  Procedures  in  procedures 

*  No  functions  or  procedures 

*  99  procedures 

4.  Filter  4 

a.  Physical  lines  /  comments  18 

b.  Constructs  19 

*  Assignments 

*  Procedure  calls 

*  Simple  If  statements 

*  Compound  If  statements 

*  Simple  If  /  Else  statements 

*  Compound  If  /  Else  statements 

*  Case  statements 

*  Repeat  Until  statements 

*  While  statements 

*  For  statements 

c.  Percentage  20 

*  Two  identical  programs  100% 

*  79%  test 

*  80%  test 

*  10%  test 

*  0%  test 

d.  Torture  21 

*  Comments  and  code  on  same  line 

*  Empty  procedure  (Begin  End;) 

*  Comment  syntax  in  literal  string 

*  Run  repeatedly  on  two  Identical 
functions 


B2 


B3 


CnteqratilQn  Teats 


Order  of 

Teats _ 


Successful 

Prereauisit< 


5.  Filter  5  B4 

a.  VARiable  declarations  “^2 

*  Array  types 

*  Boolean  types 

*  Char  types 

*  File  types 

*  Integer  types 

*  Real  types 

*  String  types 

*  User  defined  types 

b.  CONSTant  declarations  23 

*  Array  types 

*  Boolean  types 

*  Char  types 

*  User  defined  types 

*  File  types 

*  Integer  types 

*  Real  types 

*  String  types 


c.  TYPE  declarations  24 

*  Record  types 

*  User  defined 

d.  Function /Procedure  declarations  25 

e.  Total  number  of  global  declarations  26 

f.  Percentage  27 


*  Two  identical  programs  100% 

*  79%  test 

*  80%  test 

*  10%  test 

*  0%  test 

g.  Torture  28 

*  Comments  and  code  on  same  line 

*  All  code  commented  out 

*  Multiple  variables  separated 
by  commas 

Run  repeatedly  on  two  Identical 
functions 


6.  Filter  6 

a.  Keyword  and  control  statements 

*  Assignments 

*  BEGIN/END  pairs 

*  ASSIGN 

*  RESET 

*  REWRITE 

*  READ 

*  READLN 

*  WRITE 

*  WRITELN 

*  IF  statements 

*  CASE  statements 

*  REPEAT  UNTIL  statements 

*  WHILE  statements 

*  FOR  statements 

b.  Percentage 

*  Two  identical  programs  100% 

*  79%  test 

*  80%  test 

*  10%  test 

*  0%  test 

7.  Filter  7 

a.  Identifier  names 

*  Array  types 

*  Boolean  types 

*  Char  types 

*  File  types 

*  Integer  types 

*  Real  types 

*  String  types 

*  User  defined  types 

b.  Functions /Procedures 

c .  Percentage 

*  Two  identical  programs  100% 

*  79%  test 

*  80%  test 

*  10%  test 

*  0%  test 

d .  Torture 

*  Same  names  different  case 


9 


8.  Filter  8 

a.  Functions 

b.  Procedures 

c .  Percentage 

*  Two  identical  programs  100% 

*  79%  test 

*  80%  test 

*  10%  test 

*  0%  test 

d .  Torture 

*  Call  functions  declared 
in  procedures 

*  Call  procedures  declared  in 
procedures 

*  Procedure /Function  calls 
in  procedures 

*  Same  named  function  in  both 
sources,  but  local  in  one  and 
global  in  the  other 

C.  30  seconds  per  response 

D.  Help  test 

*  Main  menu 

*  Filter  1 

*  Filter  2 

*  Filter  3 

*  Filter  4 

*  Filter  5 

*  Filter  6 

*  Filter  7 

*  Filter  8 

E.  Total  percentage  test 

F.  Menu  Key  torture  test 


35 

36 

37 


38 


41 

39 


40 

42 


B7 


B8 

B8 


3.5  TEST  PROCEDURES  /  RESULTS  FORMS 


A  Test  Procedure  Form  will  be  used  to  describe  test 
procedures.  A  Test  Results  Form  will  be  used  to 
describe  the  process  £or  recording  test  results.  The 
forms  to  be  used  are  shown  in  Figures  3.5-1  and  3.5-2. 


NOTE;  The  text  enclosed  in  *<  >'  will  be  replaced  with 
the  appropriate  information  for  each  test  pro¬ 
cedure  . 


TEST  RESULTS  FORM 


Test:  <  Name  of  test  (example:  Bla)  > 

Test  Version:  <  Version  of  test  procedure  > 

Executed  By:  <  Name  of  tester  > 

Date  Test  Executed:  <  Date  test  was  executed  > 

Version  Number  Tested:  <  Version  of  software  tested,  be  sure 

to  include  beta  number  (example: 

1.0  Beta  1  > 

Test  Results  Passed  _  Failed  _  <  Usa  a  X  to  mark  the 

correct  result  > 

Problems  Identified:  <  Describe  any  problems  found  > 


Test  Steps:  <  These  are  the  actual  test  steps  that  the  tester 
followed  while  performing  the  test.  The  steps 
also  contain  the  expected  result  and  the  actual 
result  as  recorded  by  the  tester  for  each  step  > 


Figure  3.5-2 


3.6  TEST  CHECKLIST  FORM 

A  test  checklist  will  be  maintained  for  each  test 
cycle.  The  checklist  will  be  used  to  track  the  status 
of  all  tests  that  have  been  executed  during  a  test 
cycle.  An  example  of  a  test  checklist  is  shown  in 
Figure  3.6-1.  Also,  a  complete  checklist  form  can  be 
found  in  the  Appendix. 


Third  Eye  Plagiarism  Detection  System  Ver  1.0  Beta  1.0 

Test  Name 

Description 

Test 

Ver 

Run 

By 

Problem 

Report 

Numbers 

Result 
P=Pass 
F=Fail 
N=Not  Run 

A1 

Prompt  for  Pascal 
source  programs 

A2 

Exit  Test 

•  •  • 

«  •  • 

Figure  3.6-1 


3.7  PROBLEM  REPORT  FORM 


A  Problem  Report  Form  will  be  used  to  notify  the  Code 
Team  of  any  problems  found  in  the  product  during  the 
test  cycle.  The  Test  Team  will  use  the  top  half  of  the 
form  and  the  Code  Team  will  use  the  bottom  half  of  the 
form.  Each  Problem  Report  will  be  assigned  a  unique 
number  by  a  designated  member  of  the  Test  Team.  This 
designated  member  will  also  be  responsible  for  tracking 
Problem  Reports  to  ensure  that  all  Problem  Reports  have 
been  closed  at  the  end  of  the  project.  A  Problem  Report 
will  be  considered  closed  after  it  has  been  dis- 
positioned  by  the  Code  Team  and  verified  by  the  Test 
Team.  In  order  to  aid  in  the  tracking  of  the  Problem 
Reports  a  Problem  Report  Tracking  Form  will  be  used.  A 
Problem  Report  Form  is  shown  in  Figure  3.7-1  and  a 
Problem  Report  Tracking  Form  is  shown  in  Figure  3.7-2. 
Also,  blank  forms  of  the  two  forms  can  be  found  in  the 
Appendix. 


Problem  Report  Form 


PROBLEM  SUBMISSION:  PROBLEM 

Originator:  <  Name  of  tester  who  found  problem  >  REPORT  # _ 

Date:  <  Date  problem  report  is  submitted  > 

Version  Number  Tested:  <  Version  of  software  tested,  be  sure 

include  the  beta  number  (example: 

1.0  Beta  1)  > 

Problem  Description:  <  A  good  description  of  the  problem  > 

Was  the  problem  found  by  a  test?  Yes _  No _  <  Mark  with  a  X  > 

If  yes,  give  test  name:  _ 

Input:  <  Steps  leading  up  to  the  error  > 

Expected  Result:  <  What  should  have  happened  > 


Actual  Result:  <  What  actually  happened  > 


Additional  Comments;  <  Any  other  information  that  may  be 

useful  > 


PROBLEM  RESOLUTION: 

Name:  <  Name  of  coder  who  addresses  problem  > 

Date:  <  Date  problem  dispositioned  > 

Disposition:  <  Mark  with  a  X  > 

Problem  Fixed  _  Not  a  Problem  _  Duplicate  Problem  _ 

If  this  is  a  duplicate  problem  then  give  the  number  of  the 
report  on  which  this  problem  was  previously  identified  _ 

Comments:  <  Information  about  where  the  problem  was  found 

(such  as  which  subsystem)  if  the  disposition  was 
Problem  Fixed.  If  the  disposition  was  Not  a 
Problem  then  explain  why  > 


Figure  3.7-1 


Problem  Report  Tracking  Form 


Disposition: 

Fixed,  Not  a 

Report  Ver  Date  Date  Problem, 

Nximber  Tested  Reported  Returned  Duplicate  Closed 


SEQUENCE  OF  TEST  EXECUTION  FORM 

Since  the  sequence  that  tests  are  executed  can  have  an 
affect  on  weather  a  test  fails  or  not  a  Sequence  Of 
Test  Execution  Form  will  be  maintained  by  each  tester 
each  test  cycle.  The  form  is  shown  in  Figure  3.8-1  and 
a  blank  copy  of  this  form  can  be  found  in  the  Appendix. 


4 .  TEST  PROCEDURES 

The  following  pages  contain  the  actual  test  procedures  that 
are  to  be  executed  by  the  Test  Team. 


TEST  PROCEDURE  FORM 


Test:  A1  (Pascal  source  programs) 

Test  Version:  1.0 

Description:  This  test  is  performed  to  check  the  validity  of 

two  source  program  names. 

Requirements :  1 ,  2 

Prerequisites:  None 

Test  Data  Required:  TD_1A.TST,  TD_1B.TST 
Test  Steps: 

1.  Verify  system  asks  for  program  name  for  first  program. 

2.  Enter  test  data  1  through  5  from  matrix  for  first  Pascal 
name. 

Note:  In  order  to  continue  with  the  test,  the  system  must  accept 
the  valid  file  name  for  first  program  in  test  data  matrix 
nximber  5. 

3.  Verify  system  asks  for  program  name  for  second  program. 

4.  Enter  test  data  6  through  11  from  matrix  for  second  Pascal 
name. 


5.  Exit  system. 
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TEST  DATA  MATRIX  (Al) 


Test:  A2  (Exit  test) 
Test  Version:  1.0 


TEST  PROCEDURE  FORM 
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Description:  This  test  is  performed  to  check  whether  one  can 

exit  the  system  before  filter  one  is  run. 

Requirements:  4 
Prerequisites:  A1 
Test  Data  Required:  None 
Test  Steps: 

1.  Verify  system  will  allow  you  to  exit  prior  to  invoking  filter 
one. 
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TEST  PROCEDORE  FORM 
Test:  A3  (Report  information) 

Test  Version:  2.0 

Description:  This  test  is  performed  to  checlc  the  validity  of 

the  data  for  the  report  file  to  be  generated. 

Requirements:  10  through  17 

Prerequisites:  Bla 

Test  Data  Required:  TD_1A.TST  and  TD_1B.TST 
Test  Steps: 

Note:  In  order  to  continue  with  the  test,  the  system  must  accept 
the  valid  data  in  test  data  matrix,  numbers  5,  9,  13,  and 
17. 

1.  Enter  TD_1A.TST  for  first  program. 

2.  Enter  TD_1B.TST  for  second  program. 

3.  Run  filter  one. 

4.  Exit  system. 

5.  Verify  system  asks  for  report  name. 

Enter  test  data  1  through  5  from  matrix  for  report  name. 

6.  Verify  system  asks  for  course  name. 

Enter  test  data  6  through  9  from  matrix  for  course  name. 

7.  Verify  system  asks  for  Professor's  name. 

Enter  test  data  10  and  13  from  matrix  for  Professor  name. 

8.  Verify  system  asks  for  Student's  name. 

Enter  test  data  14  through  17  for  first  Student's  name. 

Enter  test  data  18  through  21  for  second  Student's  name. 

9.  Verify  report  information  in  report  file  is  same  as 
information  given  in  9,  13,  17,  and  21. 


TEST  PROCEDORE  FORM 
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Test:  B3c  (Torture) 

Test  Version :  1.0 

Description:  This  test  is  a  stress  test  for  filter  three. 

Reguirements :  3,  4,  7,  8,  18,  19,  35,  36 
Prerequisites :  B2 

Test  Data  Required:  TD_52A.TST  through  TD_53B.TST 
Test  Steps:  (Tests  are  to  be  iterative) 

For  each  iteration  of  tests,  do  one  through  seven. 

1.  Enter  program  names  given  in  the  test  data  matrix. 

2.  Run  filter  one. 

3.  Run  filter  two. 

4.  Run  filter  three  and  record  the  results  in  test  data  matrix. 

5.  Exit  after  filter  three. 

6.  Give  report  name  as  TD_B3C.RPT. 

7.  Verify  report  information  in  report  file  is  same  as  actual 
results. 
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TEST  PRCXTEDDRE  FORM 

Test:  B5a  (VARlable  declarations) 

Test  Version:  1.0 

Description:  This  test  is  performed  to  check  all  the  different 

Pascal  variable  types.  The  test  checks  to  see  if 
the  number  of  Pascal  types  are  counted  correctly 
in  the  VARiable  section  of  selected  procedures  and 
functions.  The  test  will  check  all  of  the 
following  Pascal  types:  Array,  Boolean,  Char, 

File,  Integer,  Real,  String,  and  enumerated  (user 
defined  types) . 

Requirements;  3,  4,  7,  8,  18,  19,47,  48,  52,  53 

Prerequisites:  B4 

Test  Data  Required;  TD_61A.TST  and  TD_61B.TST 

Test  Steps:  (Tests  are  to  be  iterative) 

1.  Enter  program  names  TD_61A.TST  and  TD_61B.TST. 

2.  Run  filter  one. 

3.  Run  filter  two. 

4.  Run  filter  three. 

5.  Run  filter  four.  Choose  any  procedure  names. 

For  each  iteration  of  tests,  do  six  and  seven. 

6.  Run  filter  five. 

7.  Enter  procedure  names  from  test  data  matrix 
and  record  the  results  in  test  data  matrix. 

8.  Exit  after  filter  five. 

9.  Give  report  name  as  TD_B5A.RPT. 

10.  Verify  report  information  in  report  file  is  same  as  actual 
results. 

Note:  Output  for  first  and  second  program  represented  in  form  of 
first,  second  (ex.  10,  10). 
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TEST  PROCEDURE  FORM 

Test:  D  (Help  test) 

Test  Version :  1.0 

Description:  This  test  verifies  that  the  user  will  receive 

context  sensitive  at  each  menu  level. 

Requirements:  5,  6 

Prerequisites:  B8 

Test  Data  Required:  None 

Test  Steps: 

1.  Start  system  and  request  HELP. 

2.  Verify  help  screen  appears  and  is  meaningful  for  this  level. 

3.  Exit  out  of  HELP. 

4.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

5.  Record  results  in  test  matrix. 

6.  Enter  program  names  given  in  the  test  data  matrix. 

7.  Run  filter  one. 

8 .  Request  HELP . 

9.  Verify  help  screen  appears  and  is  meaningful  for  this  level. 

10.  Exit  out  of  HELP. 

11.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

12.  Record  results  in  test  matrix. 

13.  Run  filter  two. 

14.  Request  HELP. 

15.  Verify  help  screen  appears  amd  is  meaningful  for  this  level. 

16.  Exit  out  of  HELP. 

17.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

18.  Record  results  in  test  matrix. 
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19.  Run  filter  three. 

20.  Request  HELP. 

21.  Verify  help  screen  appears  and  is  meaningful  for  this  level. 

22.  Exit  out  of  HELP. 

23.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

24.  Record  results  in  test  matrix. 

25.  Pick  any  procedure  from  first  program  and  any  procedure 
from  second  program  and  run  filter  four. 

26.  Request  HELP. 

27.  Verify  help  screen  appears  and  is  meaningful  for  this  level. 

28.  Exit  out  of  HELP. 

29.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

30.  Record  results  in  test  matrix. 

31.  Pick  any  procedure  from  first  program  and  any  procedure 
from  second  program  and  run  filter  five. 

32.  Request  HELP. 

33.  Verify  help  screen  appears  and  is  meaningful  for  this  level. 

34.  Exit  out  of  HELP. 

35.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

36.  Record  results  in  test  matrix. 

37.  Run  filter  six. 

38.  Request  HELP. 

39.  Verify  help  screen  appears  and  is  meaningful  for  this  level. 

40.  Exit  out  of  HELP. 

41.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

42.  Record  results  in  test  matrix. 

43.  Run  filter  seven. 
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44.  Request  HELP. 

45.  Verify  help  screen  appears  and  is  meaningful  for  this  level. 

46.  Exit  out  of  HELP. 

47.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

48.  Record  results  in  test  matrix. 

49.  Run  filter  eight. 

50.  Request  HELP. 

51.  Verify  help  screen  appears  and  is  meaningful  for  this  level. 

52.  Exit  out  of  HELP. 

53.  Verify  system  returns  you  to  prior  screen  before  help 
request . 

54.  Record  results  in  test  matrix. 

55.  Exit  after  filter  eight. 


LAB  NUMBER:  Oil 


TOPICfSI  FOR  LAB: 

Presentation  of  custonier  request  for  extended  project. 

INSTRUCTIONAL  OBJECTIVEfSI: 

1 .  Introduce  class  to  the  customer  for  project  2  (the  extended  project). 

2.  Familiarize  class  with  project  2. 

ASSOCIATED  LECTURE  JSUMBEB: 

Lecture  013 

SETyP..WABM-UE: 

The  requirements  for  the  your  first  (small)  projects  were  better  defined  than  is 

often  the  case.  Quite  often,  the  customer  has  nothing  more  than  a  general  idea 

of  the  type  of  system  he/she  waurts.  In  such  cases,  the  extraction  of  requirements 

is  even  more  critical  and  challenging. 

PROCEDURE: 

1 .  introduce  the  "real"  customer  to  the  class  in  order  to  explain  the  system  that 
he/she  would  like  developed.  If  the  instructor  is  acting  as  the  customer,  it 
Is  important  that  he/she  role  play  and  resist  the  urge  to  switch  roles  during 
the  lab.  The  customer  request  goes  something  like  the  following: 

"As  Dean,  I  often  have  to  make  the  final  decision,  or  make 
recommendations  to  a  university  hearing  committee,  in  academic 
misconduct  cases  involving  suspected  plagiarism  of  student 
programs  in  computer  science  courses.  I  would  like  a  system  that 
can  compare  student  programs  and  determine,  with  a  high  degree 
of  credibility,  whether  plagiarism  has  occurred.  I  need  an  analysis 
report  that  is  clear  and  understandable  and  could  be  presented  as 
evidence  to  a  university  hearing  committee. 

The  program  will  be  used  by  faculty  to  screen  student 
programs  for  possible  plagiarism  and  to  provide  an  objective  analysis 
to  support  or  negate  their  subjective  opinions.” 

The  customer  responds  to  questions. 

2.  Distinguish  between  the  customer  and  user.  For  the  extended  project,  the 
dean  is  the  customer  and  user(s)  will  be  faculty  members  and  the  dean. 

3.  Give  teams  the  remainder  of  the  time  to  work  on  the  project. 

ASSOCIATED..  HANDOUTS: 
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The  importance  of  oontroHrig  dtedplnee  in  software  development 

Configuration  management 

Ways  to  implement  configuration  management 

INSTRUCTIQNAi.  OBJECHYBS): 

1 .  Recognize  the  role  of  configuration  management  over  the  entire  Hfe 
cycle. 

2.  Develop  and  evahiate  a  configuration  management  plan. 
SETAiPJ^ABMdig: 

(How  involve  learner:  recall,  review,  relate) 

L110H4 

We  have  just  talked  about  maintenance.  Maintenance  is  change  to  software 
that  occurs  after  a  system  is  devetoped.  As  we  have  seen,  some  errors  are 
introduced  into  the  software  during  the  maintenance  process.  The 
development  of  software  is  a  continuous  process  of  change  and  affords 
developers  a  continuous  opportunity  to  introduce  errors  into  the  system. 
Some  would  consider  this  opportunity  for  the  introduction  of  error 
unacceptable.  We  cannot  alter  the  nature  of  the  development  process,  but 
if  we  manage  and  control  the  process  of  change  we  can  restrict  the 
opportunities  for  introducing  error. 

(Learning  Label-  Today  we  are  going  to  learn  ...) 

in  software  engineering,  the  prindpies  for  controlling  and  managing  change 
are  called  configuration  management.  Today  we  are  going  to  look  at  the 
principles  of  configuration  management  and  ways  in  which  configuration 
management  can  be  implemented. 


CQNIENIS: 


1 .  Motivate  the  need  for  configuration  manaqementfCMi  by  discussing 
the  simultaneous  update  problem  and  version  control.  CM  is  not  Just 
an  issue  about  software.  You  have  revised  your  small  project 
requirements  list  several  times.  Ask  the  students  what  changes  were 
made  to  the  requirements  list  and  whether  they  all  were  certain  that 
all  would  have  been  approved  by  the  customer?  Did  you  check  with 
the  customer? 


a.  Multiple  people  worWng  on  a  large  project  can  have  different 
understandings  of  what  the  system  is  supposed  to  do  or  may 
make  small  changes  which  do  not  work  well  with  other  parts  of 
the  system.  Using  the  test  plan  L90H6  remind  the  student 
that  the  test  planner  made  a  change  which  required  the  KoFF 
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system  to  track  expired  cards.  Was  this  information 
communicated  to  the  designers,  coders  or  even  to  the 
customer?  What  is  the  Hkelihood  of  this  change  made  by  the 
test  pianner  ever  getting  implemented?  What  can  be  done  to 
assure  that  these  kinds  of  changes  are  acceptable  and  will  get 
implemented?  There  is  a  need  for  control  management  and 
communication  of  change. 

b.  There  are  multiple  sources  and  reasons  for  change  requests. 
These  occur  throughout  the  development  process  as  well  as 
after  system  development.  Talk  about  change  requests  as 
desired  improvements  in  the  system.  As  the  customer  better 
understands  the  system  he/she  sees  new  and  improved  ways 
that  the  system  could  be  developed.  Changes  also  come  from 
the  developers'  improved  understanding  of  the  requirements, 
and  changes  in  the  environment  while  a  system  is  being 
developed.  This  can  lead  to  chaos  unless  carefully  managed. 

c.  Sometimes  systems  are  developed  in  different  versions,  e.g., 
DOS  2.2  >  DOS  6.0.  Each  version  of  each  system  has  to  be 
tracked  and  maintained.  Versions  are  not  always  sequentially 
developed,  as  was  DOS  4,  DOS  5,  and  DOS  6.  Sometimes 
multiple  versions  of  the  same  system  are  developed 
concurrently  to  tit  on  different  hardware  platforms,  e.g.,  UNIX 
for  DEC  and  IBM  can  be  developed  at  the  same  time.  The 
requirements  for  these  systems  are  different,  and  one  must 
track  and  maintain  multiple  versions  of  the  "same"  product. 

d.  Talk  about  baselining  as  a  technique  for  limiting  or  controlling 
this  chaos.  How  is  baselining  done?  Be  sure  to  emphasize 
that  this  involves  formal  review  and  agreement  by  all  concerned 
parties.  Once  an  item  is  baselined  it  is  under  change  control 
and  can  only  be  changed  by  formal  change  control  procedures. 
What  is  it  that  gets  baselined.  Proposed  changes  to  baselines 
are  called  Change  ReouestsfCR). 


Methods  of  CM  require  a  plan,  a  well  defined  process,  and  a  manager 
to  carry  out  the  plan. 

a.  Ask  the  class  what  things  they  need  to  keep  constant  to 
develop  a  system.  List  these  on  the  board.  Discuss  them  as 
Configuration  Items  fCI).  Display  overhead  of  standard 
configuration  items  L120H1.  Work  through  each  item  talking 
about  those  items  which  are  new  to  them.  Be  sure  to 
emphasize  that  any  change  requires  approval  and 
communication  of  the  change  as  well  as  updating  the  affected 
documents.  Another  function  of  CM  is  to  maintain  consistency 
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between  the  documentation  of  a  system  and  the  system  itself. 

b.  CM  is  complex  and  requires  a  plan  to  be  sure  it  is  executed. 
Display  overhead  L120H2.  Go  over  the  contents  of  the  IEEE 
CM  Plan.  Briefly  go  over  the  management  issues,  such  as  how 
configuration  management  relates  to  other  organizations. 
Discuss  overhead  item  2.d  which  includes  naming  conventions 
for  components  and  how  CRs  will  get  processed.  Distribute 
handout  L12HD1  as  an  example  of  a  portion  of  a  student- 
produced  CM  plan. 

c.  To  maintain  control,  baselined  configurations  items  are 
sometimes  placed  in  a  special  electronic  library.  Permission  to 
change  or  modify  Cis  is  gained  through  a  CR  approval  process. 
CRs  are  generally  approved  by  groups  called  Configuration 
Control  Boards  fCCB).  Discuss  some  standards  used  to 
decide  the  approval  of  CRs;  e.g,  functional  need,  cost  versus 
benefit  analysis,  impact  on  other  modules,  politics  (the 
president  of  the  company  "just  wants  it"). 

d.  There  are  several  virtues  of  CM  which  include  reducing  the 
number  of  errors  generated,  minimizing  the  use  of  storage, 
giving  visibility  to  system  development  progress  each  time  a 
new  Cl  is  baselined  and  reducing  the  time  and  effort  costs 
associated  with  uncontrolled  change. 


PROCEDURE: 

teaching  method  and  media: 

At  this  point  in  the  course  students  have  likely  experienced 
uncontrolled  changes  within  their  small  projects.  Some  of  these  have 
also  likely  caused  problems.  Their  own  "war  stories"  can  serve  to 
enhance  their  interest  and  appreciation  of  the  necessity  for 
configuration  management.  The  primary  teaching  technique  consists 
of  using  lecture  and  overheads  with  frequent  reference  to  problems 
they  have  encountered  in  their  small  project  teams. 

vocabulary  introduce^: 

configuration  management  (CM) 
configuration  item  (Cl) 
baseline 

discrepancies  versus  changes 
configuration  control  board  (CCB) 
change  request  (CR) 
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L120H1  Configuration  items 

L120H2  IEEE  Model  for  a  configuration  management  plan 


handouts: 

L12HD1  Student  configuration  management  plan 

RELATED  LEARNINQ-ACTIYiTJES: 

(labs  and  exercises) 

Lab  010  -  Feedback  on  Ci-S,  test  plans,  and  test  cases-Small  project 
team  preparation  for  team  acceptance  test  presentations 

READiNQ  ASSIGNMENTS: 

Sommerville  Chapter  29  (pp.  551*564) 

Mynatt  Chapter  8  (pp.  336*340) 

RELATED  READINGS: 

Ghezzi  Chapter  7  (pp.  403*408) 

Pressman  Chapter  21  (pp.  693*708) 

Schach  Chapter  4  (pp.  87*93) 

James  Tomayko,  "Support  Materials  for  Software  Configuration 

Management,"  Support  materials,  SEi_SM_4_1.0 

IEEE  Standard  for  Software  Configuration  Management  Plans.  IEEE  Std  828* 

1983 
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Configuration  Hams 


Requirements  Documents 
Client  Request 
Requirements  List 
Analysis  Documents 
Revision  History 

Revision  requests  and  approvals 

Design  Documents 

Preliminary  Design  Documents 
Preliminaiy  Design  Review  Documents 
Detailed  Design  Documents 
Detailed  Design  Review  Documents 
Revision  History 

Revision  requests  and  approvals 

Code  Documents 

Source  code  modules 
Object  code  modules 
Compiler  used 
System  build  plan 

Other  Documents 
Test  Plan 
Test  Cases 
Test  Results 
User  Manual 
Referenced  Documents 
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ippp  itocM  for  a 

CONFIGURATION  MANAGEMENT  PLAN 

1 .  Introduction 

a.  Purpose 

b.  Scope 

c.  Definitions  and  acronyms 

d.  References 

2.  Management 

a.  Organization 

b.  Configu’^)  1  management  responsibiiities 

c.  Interfax  control 

d.  Implementation  of  pian 

e.  Appiicabie  poiicies,  directives  and 
procedures 

3.  Configuration  management  activities 

a.  Configuration  identification 

b.  configuration  controi 

c.  Configuration  status  accounting 

d.  Audits  and  reviews 

4.  Toois,  techniques,  and  methodoiogies 

5.  Suppiies  Controi 

6.  Records  coiiection  and  retention 
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Coiillgiiratlon  MtnagMiMit  Plan 


PROJECT:  TNrd  Eye  Project 

FILE  NAME:  CM.PLAN.OOC 

DOCUMENT  NAME:  Configuration  Management  Plan 

PURPOSE: 

This  document  describes  the  responsibilties  of 
Configuration  Management. 

MODIFICATION  HISTORY: 
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*  Created  initiai  revision  of  document. 
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1.  PURPOSE 


The  Configuration  Management  Plan  defines  the  Configuration  Management 
(CM)  policies  which  are  to  be  used  in  the  Third  Eye  Project,  it  aiso  defines 
the  responsibilities  of  the  project  configuration  manager. 


2.  MANAGEMENT 

2.1  CONFiGURATION  MANAGER  RESPONSIBILITiES 

The  first  responsibility  of  the  configuration  manager  is  to 
develop  and  implement  this  Configuration  Management  Plan. 

Throughout  the  project,  the  configuration  manager  will  report 
directly  to  the  customer.  It  is  the  configuration  manager's 
responsibility  to  ensure  that  the  project  is  implemented  in  a 
straight-forward  and  weil-defined  manner  according  to  the 
customer’s  specifications  and  standards  established  by 
Confiouration  Management  for  this  project. 

2.2  ORGANIZATION 

This  project  will  be  divided  into  7  teams  as  follows: 

(Refer  to  CM_TEAMS.DOC  for  the  specific  team  assignments) 

NOTE:  All  of  the  documents  required  of  each  team  below 
are  listed  in  the  file  CM_DOCS.DOC. 

2.2.1  REQUIREMENTS  TEAM 

The  Requirements  Team  is  responsible  for 
communicating  with  the  customer  in  order  to  determine 
and  weil-define  the  software  system  requirements.  The 
documents  required  of  the  Requirements  Team  are: 

*  Narrative  description  of  system 

*  List  of  requirements  (acceptance  criteria) 

*  Context  Diagram 

*  A  series  of  leveled  Data  Flow  Diagrams 

*  Data  Dictionary 

*  Process  Specifications 
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2.2.2  USER  MANUAL  TEAM 

The  User  Manual  team  is  responsible  for  produdng  all 
user  documentation  for  the  system.  The  documents 
required  of  the  User  Manual  Team  are: 

*  Preliminary  format  of  user  manual 

*  User  Manual 

2.2.3  TEST  PLAN  TEAM 

The  Test  Plan  team  is  responsibie  for  det.  ling 
subsystem  and  system  tests.  The  documents  required 
of  the  Test  Plan  Team  are: 

*  Test  pism 

2.2.4  PRELIMINARY  DESIGN  TEAM 

The  Preliminary  Design  team  is  responsibie  for  creating 
a  preliminary  design  structure  of  the  system  based  on 
the  software  system  requirements.  The  documents 
required  of  the  Preliminary  Design  Team  are: 

*  An  Object  Model: 

*  Complete  object  diagram 

*  Class  dictionary 

*  Object-Requirements  traceability  matrix 

*  Ada  Specifications  for  each  object  class 

2.2.5  DETAILED  DESIGN  TEAM 

This  team  is  responsible  for  creating  algorithms  to 
implement  the  system  structure.  The  documents 
required  of  the  Detailed  Design  Team  are: 

*  Data  Structure  Design  using  a  data  structure 
dictionary 

*  Algorithm  Design  using  Nassi-Shneiderman  models 

*  An  object  attributes  and  object  operations  traceability 
matrix 

2.2.6  CODE  &  UNIT  TEST  TEAM 


9 


L12HD1 


The  Code  &  Unit  Test  team  is  responsible  for  producing 
source  code  fbr  the  algorithms  prc^oed  by  the  Detailed 
Design  Team,  integration  of  the  modules  to  produce  a 


working  system.  The  documents  required  of  the  Code 
&  Unit  Test  Team  are: 

*  Source  code 
2.2.7  TESTING  TEAM 

The  Testing  team  Is  responsible  fOr  implementing  the 
tests  in  the  test  plan  and  using  them  to  test  the  system. 
The  documents  required  of  the  Testing  Team  are: 

*  Test  data 

*  Documented  test  results 


CONFIGURATION  MANAGEMENT  ACTIVITIES 

3.1  C.M.  REOUIREMENTS  DOCUMENTS 

The  configuration  manager  has  provided  documentation  to 
assist  the  teams  in  meeting  the  C.M.  requirements.  This 
documentation  is  In  a  series  of  files  which  are  available  on  the 
project  file  server.  The  C.M.  requirements  defined  in  these  files 
are  as  follows: 

DESCRIPTION 

*  Documents  required  by  C.M. 

*  Document  header  info 

*  Document  naming  conventions 

*  Document  format  &  standards 

*  Change  request  form  format 

*  Configuration  item  rer^est  procedure 

*  Configuration  item  access  procedure 

*  Configuration  item  change  process 

*  Configuration  item  baseline  process 


3.2  C.M.  CONTROL 

The  configuration  manager  will  provide  the  teams  and  team 
members  controlled  access  to  their  respective  configuration 
items.  In  order  to  have  access,  however,  the  teams  and/or 
team  members  must  provide  the  configuration  manager  with  a 
written 


FILENAME 

CM_DOCS.DOC 

CM_HEADR.DOC 

CM_NAMES.DOC 

CM_FORMT.DOC 

CM_CHREQ.DOC 

CM_CIREQ.DOC 

CM_ACESS.DOC 

CM_CHPRO.DOC 

CM  BASLN.DOC 
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request  for  any  desired  configuration  items  as  defined  in  the  file 
CM_CIREQ.DOC. 


CONFIGURATION  MANAGEMENT  RECORDS 

All  BASELINED  Configuration  Items  and  documents  will  be  maintained  on  the 
project  file  server  in  a  directory  structure  as  defined  In  the  fifo 
CM  FILES.DOC. 


4.1  C.M.  FILES 

All  Configuration  Management  files  (Including  the  requirements 
files  listed  in  section  3.1)  are  listed  below: 

DESCRIPTION  FILENAME 


*  Configuration  item  access  procedure 

*  Configuration  item  baseline  process 

*  Configuration  item  change  process 

*  Change  request  form  format 

*  Configuration  item  request  procedure 

*  Original  customer  rec^est 

*  Documents  required  by  C.M. 

*  C.M.  file  directory  structure 

*  Change  request  form 

*  Document  format  &  standards 

*  Document  header  info 

*  Document  naming  conventions 

*  Document  page  header 

*  Configuration  Management  Plan 

*  Software  Project  Management  Plan 

*  Project  team  organization 


CM  ACESS.DOC 

CM_BASLN.DOC 

CM_CHPRO.DOC 

CM_CHREQ.DOC 

CM_CIREQ.DOC 

CM_CRQST.DOC 

CM_DOCS.DOC 

CM  FILES.DOC 

CM_FORM.DOC 

CM_FORMT.DOC 

CM_HEADR.DOC 

CM_NAMES.DOC 

CM_PGHDR.DOC 

CM_PLAN.DOC 

CM_SPMP.DOC 

CM  TEAMS.DOC 
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LAB  NUMBER:  012 

TQP.I.C{S).EQB-LAB: 

Organization  of  extended  project 

INSTRUCTIONAL  QBJECTIVE(S): 

1 .  Provide  project  organization  to  be  used  for  extended  project. 

ASSQCIAIEDJ-ECTURE  NUMBER: 

Lecture  014 

SET  U£.  WARMiUE: 

You  have  already  met  the  customer  for  the  extended  project  when  he/she 
presented  the  project  request  recently.  Today  we  will  discuss  the  team 
organization  to  be  used  for  the  extended  project. 

PROCEDURE: 

1 .  HANDOUT  -  List  of  teams  in  extended  project  organization 

Distribute  and  describe  the  roie  and  responsibilities  of  each  team. 

a.  Explain  that  during  this  semester  the  project  will  be  completed 
through  preliminary  design.  Thus  the  teams  that  will  be  active  during 
this  semester  are  configuration  management,  requirements,  user 
interface,  test  plan,  and  preliminary  design  (and  tools  if  a  tools  team 
in  included  in  the  project  organization). 

b.  During  the  course  of  the  project  each  student  will  serve  on  more 
than  one  team.  In  particular,  each  student  will  serve  on  a  "high  end" 
team  (encompasses  analysis  through  preliminary  design)  and  a  "low- 
end"  team  (encompasses  detailed  design  through  implementation). 

c.  Communication  will  be  more  complex  in  this  project  than  in  your 
small  projects.  Both  inter-team  and  intra-team  communication  will  be 
necessary,  as  well  as  communication  with  the  customer  and  users. 
For  example,  crucial  interactions  from  the  beginning  will  include: 

Configuration  management  with  instructor  and  all  other  teams. 

Requirements  team  with  customer,  user,  and  other  teams. 

User  interface  team  with  user  and  requirements  team. 

Test  plan  team  with  requirements  team  and  user  interface. 

d.  Four  teams  will  begin  work  as  soon  as  the  team  assignments  are 
made.  Configuration  management  will  begin  developing  a  CM  plan, 
requirements  will  begin  eliciting  and  specifying  the  requirements. 
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user  interface  will  begin  on  the  format  of  the  users  manual  and  the 
"look  and  feel"  of  the  user  interface,  test  plan  will  begin  developing 
the  format  of  the  test  plan. 

Invite  any  students  with  a  preference  for  specific  team  assignments  to  let  instructor 
know  as  soon  as  possible.  Let  students  know  that  they  cannot  be  guaranteed  their 
preferences  but  that  they  will  be  considered. 

ASSOCIATED  HANDOUTS: 

List  of  teams 

Extended  project  team  organization 
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EXTEMDED  PROJECT  TEAMS 

Configuration  management 
Requirements 
Test  plan 
User  Interface 
Preliminary  design 
Detailed  design 
Code  and  unit  test 
Testing 

Tools  (optional) 
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NOTE:  Preliminary  design  team  will  be  subdivided  into  two  or  more  teams  when 


LAB  NUMBER:  013 

TQPiC(S)  FQfl  LAB: 

Peer/seif  assessment  •  small  projects 
Acceptance  reviews  •  small  projects 

INSTRUCTIONAL  QBJECTIVEfSI: 

1 .  Provide  opportunity  for  peer/self  assessment  of  small  project  teams. 

2.  Simulate  acceptance  test/re\^ew  for  small  projects. 

ASSQCIATEP  LECTURE  NUMBER: 

Lecture  015 

As  discussed  in  our  first  class  meeting,  we  want  to  consider  your  opinions  in 
assessing  the  team  projects.  We  have  prepared  a  peer/seif  evaluation  instrument 
and  will  be  administering  it  today,  prior  to  your  acceptance  test  presentations. 
Immediately  following  that  we  will  conduct  the  acceptance  test  presentations. 

PROCEDURE: 

1.  HANDOUT  *  Peer/self  evaluation  forms  for  small  projects 

Ask  each  student  to  complete  a  peer/self  evaluation  form  for  his/her  team. 
Stress  that  their  responses  are  confidential  and  will  be  seen  by  the 
instructor  only.  While  feedback  will  be  provided  to  individuals,  the 
confidentiality  of  responses  will  remain  strictly  confidential. 

ASSOCIATED.  HANDQUIS: 

Peer/self  evaluation  forms  for  small  projects 
Oral  presentation  evaluation  form 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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KIOSK  TEAM:  PEER^ELF  EVALUATION 


Your  imponti  at#  confldwitMi  and  witi  bt  mn  only  by  ttm  Instructors.  Bo 
eompMoly  honoot  Uao  bock  for  additional  commonto. 


1 .  Evaluate  the  performance  of  each  team  member,  indudirw  yourself  with  respect 
to  each  of  the  following  questions  by  indicating  8A  (strongly  agree),  A  (agree),  D 
(disagree),  or  SD  (strongly  disagree). 


Ha/aha  took  a  fair  ahara  of  tha 
raaponalbllity  and  work. 

Ha/aha  took  a  laadarahip  rola. 


Ha/aha  kapt  aware  of  tha  projact'a 
problams  and  prograsa. 


Ha/aha  la  knowladgaabla  of  tha 
tools  and  tachniquas  usad. 


Ha/aha  attandad  maatings  and 
cooparatad  with  rest  of  team. 


Ha/aha  gava  an  honast  affort 
and  compiatad  tasks  on  tima. 


I  would  ehooaa  to  work  with 
him/har  on  anothar  projact 
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2.  Complete  Columns  A  and  B  for  each  team  member,  including  yourself. 

COLUMN  A:  Enter  or  •  as  follows. 

•t-  means  this  person  made  a  significant  contribution  to  the  team  and 
should  be  given  a  bonus;  their  Individual  project  grade  should  be 
higher  than  the  team  grade. 

>  means  this  person  did  their  share;  their  individual  project  grade 
should  be  equal  to  the  team  grade. 

means  this  person's  performance  was  less  than  adequate  and 
his/her  individual  project  grade  should  be  lower  than  the  team 
grade. 

COLUMN  B:  Describe  his/her  major  contributions. 

(A)  (B) 

■■  -TEAM  MEMBER  ±jlz  MAJOR  CONTRIBUTION'S) 

1. 


2. 


3. 


4. 


5. 


6. 
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3.  For  each  Hem  below,  me  your  team'a  pertennance  and  dellverablee  omdueed. 
UNS  represents  unsatisfactory  and  EXC  represents  exosHent. 


(a)  Interaction  wHh  user  in  understanding/ciefining  requirements 
BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(b)  Configuration  Hern  1  •  narrative  description  (abstract)  of  project  and 
requirements  list. 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(c)  Configuration  Hern  2  •  analyst  documents:  context  diagram,  levied  data 
flow  diagrams,  data  dictionary. 

BELOW  ABOVE 

UNS  AVQ  AVQ  ^  AVQ  EXC 


(d)  Configuration  Hem  3  •  design  documents:  system  archHecture  (structure 
chart  and  external  description  of  modules  and  interfaces). 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(e)  Configuration  Hems  4  and  5  •  test  plan  (classes  of  tests  for  each 

requirement);  test  scenarios  (specific  tests,  input,  expected  output,  etc.) 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 


(f)  Configuration  items  6  and  7  •  documented  source  code;  executable. 
BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 
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(g)  Confiotirilion  Item  8  •  documentation  of  tasting;  acoeptenoe  tasting 
ptans,  documentation,  elc. 

WmJOHM  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(h)  Configuration  Hem  7  •  Acceptance  test  review 
BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(i)  Overall,  rata  the  your  team's  performance  for  the  entire  project? 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


(j)  Overall,  the  tools  team  and  the  materials  they  have  produced  have  been 
NO  LITTLE  MUCH 

HELP  HELP  OK  HELP  HELP 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


4.  If  you  had  to  do  this  project  again  and  were  in  charge  of  hiring  personnel,  in 
what  order  would  you  rehire  the  team?  In  other  words,  who  would  be  the 
person  on  your  team  you  would  rehire  first,  second,  third,  etc.?  (Be  sure  to 
include  yourself). 

1. 

2. 

3. 

4. 

5. 

6. 
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LAB  NUMBER:  014 


TQPIC(S)  FOR  LAB: 

Assessment  of  small  projects. 

Team  assignments  for  extended  projects. 


1. 

2. 


3. 

4. 


QBJECTiYBS): 


Provide  assessment  of  products  produced  by  teams. 
Provide  assessment  of  individual  team  members. 


Organize  teams  for  extended  project. 

Provide  software  project  mara^jement  plan  for  extended  project. 


ASSOCIATED  LECTURE  NUMBER: 
Lecture  016 


SET  UP.  WARM-UP: 

Recall  that  the  course  policies  explained  that  there  were  three  factors  to  be 
considered  in  your  individual  project  grades:  foe  product  produced  by  foe  team, 
peer  assessment  of  individual  contributions  to  the  team  effort,  and  the  instructorfs)' 
assessment  of  individual  contributions.  Today  each  of  you  will  receive  a  copy  of 
our  assessment  of  your  project  with  a  team  project  grade  and  with  an  individuai 
grade  for  your  contribution  to  the  project.  We  will  then  announce  foe  team 
assignments  for  foe  extended  project. 


PROCEDURE: 

1 .  Distribute  individual  assessment  reports  containing  the  product  grade,  the 
individual  grade,  and  extended  comments  on  foe  product. 

2.  Invite  teams  or  individuals  to  make  appointments  to  discuss  the 
assessments.  Stress  that  we  will  discuss  foe  peer/self  assessments  with 
individuals  but  only  in  composite  terms;  confidentiality  will  be  maintained. 

3.  Announce  team  assignments  for  extended  project.  Distribute  team  rosters. 

4.  HANDOUT  -  Software  project  management  plan  for  extended  project 
Distribute  and  discuss  foe  project  management  plan. 

5.  Teams  are  given  the  remaining  time  for  organizational  meetings. 

ASSOCIATED  HANDOUTS: 

Small  project  team  evaluations  (samples  attached) 

Rosters  for  extended  project  teams 

Software  project  management  plan  -  extended  project 
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PROJECT  1  EVALUATION:  KIOSK  VENDINQ  MACHINE  SYSTEM 


TEAM  MEMBER: _ 

TEAM  PRODUCT  GRADE: _  TEAM  MEMBER'S  GRADE: _ 

_ COMMENTS  ON  PEUYERED  PRODUCT _ 

These  commente  pertain  to  the  dellveied  aofhware  product  and  are  not  neoeasarlly 
reflective  of  the  time  and/or  effort  expended. 


The  quality  of  the  delivered  document  was  first  rate.  There  were,  however,  several 
problems  which  made  the  system  less  than  perfect.  Most  of  the  comments  below  are 
items  of  clarification.  Our  major  concerns  with  your  product  were  about  the  structure 
chart,  the  coded  system  that  was  delivered,  and  the  absence  of  interface  descriptions. 

There  were  several  concerns  about  the  data  dictionary. 

Physical  money  and  amount  representation  still  gave  you  some  problems,  e.g., 
change  and  current  amount  are  defined  the  same,  yet  one  represents  physical 
money  and  the  other  is  a  representation  of  money.  Refund  has  a  similar  problem. 

Hama  needs  iteration. 

slot  number-  The  iteration  is  for  the  number  of  integers  in  the  slot  number  and  not 
for  the  range  of  numbers.  The  numerals  1  to  32  are  either  integer  4  integer  or 
integer  with  a  lower  bound  of  1  for  the  numerals  0  to  9  and  an  upper  bound  of  2 
for  the  numerals  10  to  32. 

In  a  context  diagram  you  should  use  nouns,  e.g.,  dispense  and  cancel  are  not  nouns. 

We  had  some  questions  about  the  level  0  DFD.  Alarm  status  is  not  accessed  at  all.  Its 
function  is  not  clear. 

Data  stores  in  a  DFD  should  appear  only  on  one  level,  but  running  total  data  and  stock 
store  each  appear  on  two  levels. 

The  structure  charts  created  several  problems. 

There  was  no  top  level  structure  chart  for  your  system.  What  is  the  system  you 
intend  to  deliver  to  the  customer?  This  is  a  mayor  problem. 

There  should  not  be  multiple  information  items  on  data  couples. 

The  structure  chart  and  the  code  should  agree  at  least  in  terms  of  the  number  of 
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inputs  and  outputs.  This  is  not  the  case.  See  for  example  dispense  items  and 
validate  selection.  The  source  code  and  the  design  should  agree.  One  should 
map  the  other,  i.e.,  logically  they  should  be  in  the  same  order  even  if  the  code 
breaks  things  down  into  smaller  modules. 

The  process  narratives  were  well  done! 

Interface  descriptions  were  missing. 

CODE  The  customer  has  no  code!  The  customer  was  given  a  test  scaffold  which  ties 
together  several  discrete  modules  to  enable  an  acceptance  test.  Where  is  the  system 
that  the  customer  can  run  once  the  test  is  done? 

TESTING  There  are  no  results  recorded  on  any  of  the  test  result  forms.  The  only 
difference  from  one  test  result  form  to  the  next  is  the  requirements  number  on  the  form. 
There  should  have  been  some  major  concerns  with  some  of  the  tests,  for  example  the 
dispense  test  doesn't  check  to  see  if  the  quantity  in  a  slot  has  been  decreased  after  an 
item  was  dispensed.  These  forms  indicate  that  version  1.0  was  tested  and  yet  the 
documents  indicate  that  version  2.0  was  submitted. 
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PROJECT  1  EVALUATION:  FIRE  AND  SECURITY  ALARM  SYSTEM 


TEAM  MEMBER: _ 

TEAM  PRODUCT  GRADE: _  TEAM  MEMBER'S  GRADE: _ 

_ COMMENTS  ON  DELIVERED  PRODUCT 

ThMt  comments  pertsln  to  the  delivered  eoftwsre  product  end  ere  not 
neceeeerily  reflective  of  the  time  end/or  effort  expended. 

OVERALL  PACKAGING  >  Product  gives  appearance  of  having  been  thrown  together 
at  last  minute,  including  some  Herns  being  crossed  out  and  others  being  penciled  in. 

NARRATIVE  DESCRIPTION  -  In  paragrsq|>h  7.  "same  span  of  time  ....  ”  is  still  vague 
to  be  tested. 

REQUIREMENTS  UST 

#9  and  Footnote  are  inconsistent  one  another. 

#13,  #15:  indentation  erratic. 

#20:  incident  reports  and  frequency  reports  never  fully  defined. 

CONTEXT  DIAGRAM,  DFDe,  DATA  DICTIONARY 

Some  items  missing  from  data  dictionary,  including: 

Notify 

Incident  report 
Frequency  report 
Incidents 

Signal  to  Fire  Equipment 
Signal  to  Warning  Device 
Signal  to  Lock/Unlock 
Room  Function 

Data  stores  not  defined  in  data  dictionary. 

Use  of  "Flag"  in  data  dictionary  is  still  awkward.  It  would  be  much  more 
meaningful  to  do  something  like  the  following: 

Hazatid  level  >  High  |  Normal 
Type  >  Fire  |  Security 

Alarm  condition  >  In-servioe  |  Out-of-Service 
In  places,  more  meaningful  names  could  be  used;  e.g.,  Type  is  too  vague. 
Context  diagram  and  DFD  are  not  balanced:  leveling  of  DFD  incomplete. 
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DFD  is  rough;  far  from  form  expected  in  finished  product. 
As  shown  in  model.  SetUpFile  should  be  an  external  entity. 


DESIGN  DOCUMENTS 

No  external  description  of  module  and  interface  submitted. 

Various  inconsistencies  or  omissions  in  structure  chart;  for  examnple  Get  Info 
(page  2)  doesnl  return  any  Information. 

Module  (and  procedure)  names  should  always  be  as  descriptive  as  possible 
and  consist  of  Verb  and  Object. 


CODE 

Design  and  code  are  inconsistent. 

In  places  it  is  tough  to  distinguish  between  test  modules  and  product  modules; 
for  example  the  OurTime  procedure. 

Programming  standards  were  not  followed  in  several  aspects  including  identifier 
dictionaries,  input  and  output  descriptions,  use  of  meaningful  identifier  names 
(for  example,  look  at  TimeCompare  and  TimeSubtract). 

Inconsistent  documentation  blocks  (for  example,  none  on  Init  and 
CallProcedures). 

Comments  •  look  at  11.7  of  programming  standards. 

What  is  purpose  of  procedure  CallProcedures? 

TEST  PLAN,  TEST  RESULTS 

Test  categories  too  broad;  for  example  consider  Section  C  (Alarm  Responses)  - 
these  need  to  be  broken  down  further  to  adequately  test  system. 

Test  procedure  form:  (a)  all  look  like  low-level  unit  tests;  (b)  all  end  with  the 
generic  statement  "Verify  test  data  is  output  to  test  result  file.”  Should  also 
worry  about  correctness  of  output. 

Test  results  somewhat  confusing  and  appear  inadequate;  not  mappable  to  test 
procedures. 
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Softwara  Project  Management  Plan:  Extended  Project 

Week-Class  Description 


la 

Customer  request  presented. 

2b 

Team  assignments  announced  and  roles  defined. 

Start  development  of  configuration  management  plan 
(CMP),  preliminary  requirements  (P.REQ),  preliminary  test 
plan  (P_TP),  and  preliminary  user's  manual  (P_UM). 

4b 

CI-1 

CMP  delivered  and  presentation  to  teams. 

5a 

CI-2 

P_REQ  delivered;  presentation  to  teams  and  customer. 

CM 

P_UM  delivered;  presentation  to  teams. 

5b 

CI-3 

P_TP  deiivered;  presentation  to  teams. 

6a 

Requirements  review.  Preiiminary  design  begins. 

6b 

CI-5 

Final  revised  requirements  baselined. 

8b 

Preliminary  design  review. 

9a 

User  manual  review 

Test  plan  review 

9b 

CI-6 

Final  preliminary  design  delivered  and  baselined 

CI-7 

Final  test  plan  delivered  and  baselined 

CI-8 

Final  user  manual  delivered  and  baselined 

14a 

Detailed  design  review 

14b 

CI-9 

Detailed  design  deiivered  and  baselined 

19a 

Unit  tested  code  goes  to  integration  testing 

21a 

CI-10 

Source  and  ot^ect  code  delivered 

21b 

CM1 

System  acceptance  test  conducted  and  the  complete 
system  and  all  associated  documents  are  packaged  and 
deiivered  to  the  customer 

NOTE:  All  presentation/review  Itema  are  diatrlbuted  to  designated 

reviewers  24  hours  prior  to  the  presentation/review. 
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LAB  NiiMBEB:  015 


TOPICiS.)  FflBlAB,: 

Initial  user  perspective  of  extended  project 
INSTRUCTIONAL  QBJECTiVEfS^: 

1 .  Provide  perspective  of  user  of  system  to  be  developed  for  extended  project 

ASSQCIATBD  LECTURE  NUMBER: 

Lecture  017 

SET  UP.  WARM-UP: 

You  have  already  met  the  customer  for  the  extended  project  when  he/she 
presented  the  project  request  recently.  Today  a  prospective  user  of  the  system 
is  going  to  present  his/her  perspective  and  answer  any  questions  you  might  have. 
Following  your  meeting  with  the  user  we  will  discuss  the  project  organization  to  be 
used  for  the  extended  project. 

PROCEDURE: 

1 .  Remind  the  students  of  the  difference  between  the  customer  and  the  user. 
Then  introduce  the  user  to  give  his/her  initial  view  of  the  system  and  to 
answer  any  questions. 

NOTE:  It  is  important  to  plan  in  advance  requirements  that  are  to  be 
explicitly  identified  by  the  user  cNjring  this  discussion  and  requirements  that 
will  be  mentioned  only  if  elicited  by  student  questions.  For  example, 
consider  the  piagiarism  detection  system  described  previously  by  the  dean 
(customer).  For  this  system,  the  items  boided  below  are  to  be  explicitly 
communicated  by  the  user;  non-bolded  items  beiow  wiil  be  communicated 
during  requirements  extraction  process  as  appropriate  questions  arise. 

Input  is  two  Pascal  source  programs,  from  CS-1  and  CS-2  students. 

Want  menu-driven  Interaotivs  system. 

See  system  as  a  series  of  filters  with  a  stop  after  each  filter  to  show 
filter's  results  and  for  a  Go/No-Qo  response  from  the  user. 

Output  report  produced  at  each  filter  sumnwrlzlng  its  results. 

First  level  (filter):  #  lines  of  code  (Pascal  statements) 

#  lines  of  comments  ( between  { } ) 
total  #  physical  lines  (soln's) 


Second  level  (filter)  -  considers  main  (global)  declarations 

#  variables  #  variables  by  type 
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#  user-defined  types 

#  constants 


#  procedures  declared 

#  functions  declared 


Third  level  (filter)  -  considers  struchve  of  prooedure^nction 
Irrterfaces 

parameters,  type,  order 

Fourth  level  (filter)  -  Filter  1  applied  to  selected  procedurea^ncUons 

Fifth  level  (filter)  -  Filter  2  applied  to  selected  procedurea/functions 

Sixth  level  (filter)  •  considers  statemsnt  types  fdr  main  body  only 

Frsquenciea  for  aaaignmsnts,  reads  &  readins.  writes  &  wrltelns,  IFs, 
WHILES,  FORa,  REPEAT-UNTILs,  CASES,  BEGIN-ENDs 

Seventh  level  (filter)  -  consider  name  matching 

Eighth  level  (filter)  -  adherence  to  standards  (?) 

unusual  structures  (BEGIN-END  problems,  etc) 

2.  The  user  answers  questions. 

ASSOCIATED  HANDOUTS: 

Extended  project  team  organization 
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1^  NUMBER:  016 


TQPIC(S)  FQRIAB: 

Immediate  tasks  for  configuration  management,  requirements,  user  interface,  and 
test  plan  teams. 

INSTRUCTIONAL  OBJECTiVEfS): 

1 .  Begin  work  on  deKverabies  for  extended  project 

ASSOCIATED  UECTURE  NUMBER: 

Lecture  018 

SET  UP.  WARM-UP: 

in  recent  labs  the  project  organization  has  been  explained  and  team  assignments 
made.  The  customer  and  a  user  have  given  their  perspectives  on  what  te  needed. 
Each  of  you  has  been  assigned  to  a  team.  Today  we're  going  to  talk  efoout 
immediate  tasks  and  give  you  time  to  work  on  the  project. 

PROCEDURE: 

1 .  For  each  team,  discuss  the  work  that  needs  immediate  attention. 

a.  Configuration  management 

i  Read  Sommerviile  Chapter  29; 

ii  Begin  draft  of  CM  plan 

b.  Requirements  •  Begin  requirements  definition 

c.  User  interface 

i  Read  Mynatt  Appendix  B 

ii  Begin  developing  user  manual  format 

iii  Begin  considering  "look  &  feel”  of  system 

d.  Test  plan  >  Begin  developing  test  plan  format 

e.  Tools  (optional) 

i  Begin  identifying  development  tools  to  be  used  and  begin 
developing  expertise  in  their  use 

ii  Begin  planning  training  and  training  materials  in  tools  use 

2.  Stress  the  importance  of  communication  between  teams. 

3.  Provide  each  team  with  a  suitable  work  area  and  give  them  this  time  to 
work  on  their  immediate  tasks.  The  instructor  and  the  user  should  be 
available. 

ASSOCIATED  HANDOUTS: 
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LAB-taUMBER:  017 


TQPICfSI  FOR  LAB: 

Configuration  management  plan  presentation/review 
INSTRUCTiONAL  QBJECTiVEfS^: 

1 .  Configuration  manager  presents  configuration  management  plan  for  review. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  020 

SET  UP.  WARM-UP: 

Remind  students  that  the  purpose  of  these  reviews  are  to  improve  the  item  under 
review.  All  participants  (developers,  customers,  and  other  reviewers)  have  a 
common  goal:  to  identify  issues  that  need  to  be  addressed. 

Remind  them  as  well  of  some  of  the  guideHnes  for  reviews  that  have  been 
discussed  in  the  past,  include:  during  the  review  we  want  to  identify  problems,  not 
attempt  to  solve  them;  avoid  the  tendency  to  resist  change  or  be  defensive; 
remember  this  is  a  team  effort. 

Remind  them  to  note  any  issues  identified  that  require  attention  and  to  follow  up 
on  the  issues  list  as  soon  as  possible. 

PROCEDURE: 

1 .  Introduce  the  configuration  manager  and  begin  the  review. 

ASSOCIATED  HANDOUTS: 

Oral  presentation  evaluation  form 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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LAB  NUMBER:  018 


TQPICiS)  fiORiAB: 

Preliminary  requirements  presentation/review 
Preliminary  users  manual  presentation/review 

INSTRUCTIONAL  QBilECTIVECS): 

1 .  Requirements  team  presents  preKminary  requirements  for  review. 

2.  User  interface  team  presents  format  of  users  manusd  for  review. 

ASSQCIATEP  LECTURE  NUMBER: 

Lecture  021 

SET  UP.  WARM-UP: 

Remind  students  that  the  purpose  of  these  reviews  are  to  improve  the  item  under 
review.  All  participants  (developers,  customers,  and  other  re>newers)  have  a 
common  goal;  to  identify  issues  that  need  to  be  addressed. 

Remind  them  as  well  of  some  of  the  guidelines  for  reviews  that  have  been 
discussed  in  the  past.  Include:  during  the  review  we  want  to  identify  problems,  not 
attempt  to  solve  them;  avoid  the  tendency  to  resist  change  or  be  defensive; 
remember  this  is  a  team  effort. 

Remind  them  to  note  any  issues  identified  that  require  attention  and  to  follow  up 
on  the  issues  list  as  soon  as  possible. 

PRQCEBUBE: 

1 .  Discuss  briefly  the  need  for  each  team  to  carefully  review  the  work  of  other 
teams.  This  is  particularly  important  to  assure  consistency  between  teams 
requirements,  user  interface,  test  plan,  and  configuration  management. 

2.  Introduce  the  requirements  team  and  begin  the  review. 

3.  Introduce  the  user  interface  team  and  begin  the  review. 

ASSOCIATED  HANDOUTS: 

Oral  presentation  evaluation  form  (2) 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 


1 


Lab  018 


LAB  NUMBER:  019 

TOPICfSI  FOR  LAB: 

Preliminary  test  plan  prasentation/review 


INSTRUCTiONAL  PBJSCJIVEIS): 

1 .  Teat  plan  team  presents  preliminary  test  plan  for  review. 


ASSQCIAT5P.L£.CTURS  NUMBER: 

Lecture  022 


SET  UP.  WARM-UP: 

Remind  students  that  the  purpose  of  these  reviews  are  to  improve  the  item  under 
review.  All  participants  (developers,  customers,  and  other  reviewers)  have  a 
common  goal:  to  identify  issues  that  need  to  be  addressed. 

Remind  them  as  wall  of  some  of  the  guidelines  for  reviews  that  have  been 
discussed  in  the  past.  Include:  during  ttre  review  we  want  to  identify  problems,  not 
attempt  to  solve  them;  avoid  the  tendency  to  resist  change  or  be  defensive; 
remember  this  is  a  team  effort. 


Remind  them  to  note  any  issues  identified  that  require  attention  and  to  follow  up 
on  the  issues  list  as  soon  as  possible. 

PROCEDURE: 

1 .  Discuss  briefly  the  need  for  each  team  to  carefully  review  the  work  of  other 
teams.  This  is  particularly  important  to  assure  consistency  between  teams 
requirements,  user  interface,  test  plan,  and  configuration  management. 

2.  Introduce  the  test  plan  team  and  begin  the  review. 

ASSOCIATED- HANDOUTS; 

Oral  presentation  evaluation  form 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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1 


LAB  NUMBER:  020 

TQPICfS^  FOR  LAB: 

Rnal  requirements  presentatlon/^view 

INSTRUCTIONAL  QBJECTIVEfS^: 

1 .  Requirements  presents  final  requirements  for  review. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  023 

SET  UP,  WARMrUP: 

The  work  of  all  of  the  teams  has  been  carefully  reviewsd  by  all  of  you.  This  began 
with  a  review  of  the  preliminary  requirements  followed  by  user  interface  and  test 
plan  reviews,  respectively.  During  each  review  issues  have  arisen  that  needed  to 
be  addressed.  Some  issues  identified  involved  inconsistencies  in  the  way  (Sfferent 
teams  were  interpreting  aspects  of  the  system.  We  expect  that  reviewing  other 
teams'  work  has  caused  each  of  you  to  examine  your  own  work  in  an  effort  to 
resolve  the  inconsistencies. 

By  this  time  all  issues  should  have  been  addressed  and  should  be  reflected  in 
modifications  to  the  appropriate  documents.  Likewise  they  should  be  reflected  in 
today's  requirements  review. 

As  always,  remind  students  to  note  any  issues  identified  that  require  attention  and 
to  follow  up  on  the  issues  list  as  soon  as  possible. 

PROCEDURE: 

1 .  Stress  the  importance  of  this  review.  The  requirements  will  be  baselined 
once  issues  uncovered  in  this  review  have  been  addressed.  Point  out  the 
importance  of  this  baseline  to  provide  a  stable  base  for  design. 

2.  Introduce  the  rec^irements  tecun  and  begin  the  review. 

ASSOCIATED  HANDOUTS: 

Oral  presentation  evaluation  form 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 


LAB  NUMtSbH:  QZO 

TQPICCS)  FOR  LAB: 

Rnai  requirements  presentation/review 

HiSTRUQTlQMAL.  OBJECTIVES): 

1 .  Requirements  presents  final  requirements  tor  review. 

ASSQCiATeP  LECTURE  NUMBER: 

Lecture  023 

SSI  UE..WARM:UP: 

Ttie  work  of  all  of  the  teams  has  been  carefully  reviewed  by  ail  of  you.  This  began 
with  a  review  of  the  preliminary  requirements  followed  by  user  interface  and  test 
plan  reviews,  respectively.  During  each  review  issues  have  arisen  that  needed  to 
be  addressed.  Some  issues  identified  involved  inconsistencies  in  the  way  (Afferent 
teams  were  interpreting  aspects  of  the  system.  We  expect  that  reviewing  other 
teams'  work  has  caused  each  of  you  to  examine  your  own  work  in  an  effort  to 
resolve  the  inconsistencies. 

By  this  time  all  issues  should  have  been  addressed  and  should  be  reflected  in 
modifications  to  the  appropriate  documents.  Likewise  they  should  be  reflected  in 
today's  re()uirements  review. 

As  always,  remind  students  to  note  any  issues  identified  that  require  attention  and 
to  follow  up  on  the  issues  Hst  as  soon  as  possible. 

PROCEDURE: 

1 .  Stress  the  importance  of  this  review.  The  requirements  will  be  baselined 
once  issues  uncovered  in  this  review  have  been  addressed.  Point  out  the 
importance  of  this  baseline  to  provide  a  stable  base  tor  design. 

2.  Introduce  the  requirements  team  and  begin  the  review. 

ASSOCIATED  HANDOUTS: 

Oral  presentation  evaluation  form 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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LAB  NUMBER:  021 


TQPtC(S)  FOR  LAB: 

Preliminary  design 

INSTRUCTIONAL  OBJECTIVEfSI: 

1 .  Steer  preliminary  design. 

At  this  point  the  extended  project  teams  are  approaching  a  critical  juncture. 
The  instructor  needs  to  have  a  thorough  understanding  of  where  the  teams 
are  heading.  This  understanding,  of  course  comes  form  a  variety  of 
sources:  reviews,  interactions  with  those  involved  in  the  project  (student 
teams,  customer,  user),  and  "unoffidai"  comments  from  incfividual  students 
on  team  progress.  Generally  a  number  of  different  approaches  have  been 
suggested  by  different  students.  In  order  to  Increase  the  chances  for 
successful  completion  of  the  project,  the  instructor  may  need  to  steer  the 
design,  issues  the  students  may  not  be  aware  of  inciude  hardware 
constraints  and  language  capabilities  and  constraints.  Appropriate  steering 
may  involve  guiding  students  towards  a  particular  design  approach  and/or 
away  from  potential  pitfalls. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  026 

SET  UP.WARM-iiE.: 

Today  we  want  the  project  teams  to  continue  work  on  the  project.  There  are 
several  issues  on  which  we  need  clarification  and  which  we  weint  to  ask  about  as 
we  visit  with  teams  during  the  lab. 

PROCEDURE: 

1.  Informally  meet  with  individued  teams  or  entire  class,  whichever  is 
appropriate,  and  provide  necessary  steering. 


ASSOCIATED  HANDOUTS: 
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LAB  NUMBfR:  022 


TOPICfS^  FOR  LAB: 

Ada  laboratory  environment 

INSTRUCTIONAL  QBJECTIVE(S): 

1 .  Be  acquainted  with  the  Ada  en^ronment  on  the  machines  in  our  local  lab. 

2.  Understand  how  to  enter  and  compile  a  Ada  source  program  in  lab. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  027 

SET  UP.  WARM-UP: 

You  will  be  implementing  the  extended  project  in  Ada.  Today  we  want  to  explain 
the  Ada  tools  and  environment  that  you  will  be  using  and  let  you  begin 
experimenting  with  them. 

NOTES:  1 .  Develop  a  short  handout  on  your  particular  Ada  environment. 

This  should  include  instructions  for  accessing  all  tools  and  for 
editing,  compiling,  linking,  and  executing  Ada  programs. 

2.  If  a  tools  team  is  used,  they  should  be  responsible  for  all  or 
part  of  this  laboratory. 


PROCEDURE: 

1 .  HANDOUT  •  Description  of  Ada  laboratory  environment 

In  the  lab,  walk  through  the  hcmdout  with  students. 

a.  The  Ada  compiler  is  our  lab  is  a  line  editor  which  is  not  the  most 
user-friendly  environment  to  work  in;  therefore,  we  have  set  up  the 
lab  so  that  Turbo  Pascal  editor  Is  on  every  machine  with  the  Ada 
compiler.  You  can  enter  your  programs  using  the  Turbo  Pascal 
editor  and  then  exit  to  compile  the  program  using  the  Ada  compiler. 

b.  Before  using  the  Ada  compiler,  you  must  set  up  the  Ada  environment 
on  your  diskette  in  the  A  drive.  The  command  necessary  to  set  of 
the  Ada  environment  is  ne¥vtfb  which  only  has  to  be  done  once  for 
each  diskette.  This  command  will  create  an  ADA.LIB  program  and 
an  ADA.AUX  directory  on  your  diskette.  This  command  creates  a 
local  library  database  that  references  the  standard  library  database 
file  provided  by  the  compiler.  A  link  from  your  diskette  back  to  the 
Ada  compiler  in  the  C:\ADA  directory  is  also  established.  All  your 
work  should  be  done  on  the  A  drive.  The  next  commands  are 
shown  using  the  A  drive  prompt. 

c.  In  order  to  compile  a  program,  the  Ada  compiler  must  be  invoked 
with  the  source  code  file  name.  For  this  example,  let's  say  that  the 
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program  just  created  was  in  a  file  named  "try.ada"  and  the  name  of 
the  main  program  (the  internal  name  of  the  program)  was  Iry".  To 
compile  an  Ada  programming  unit,  type  the  following  at  the  prompt: 

A:\>ada  try.ada 

You  must  include  the  file  extension  when  compiling.  This  command 
will  indicate,  in  its  screen  output,  the  line  number  and  type  of  error 
for  any  compile  errors  encountered  in  the  program.  The  Turbo 
Pascal  editor  gives,  as  you  move  through  a  program,  the  current  line 
number  on  the  bottom  left  of  the  screen;  these  line  numbers  are  in 
agreement  with  the  line  numbers  given  by  the  compiler  on  error 
messages. 

All  programming  units  must  be  compiled  in  the  order  of  their 
dependency.  The  final  programming  unit  to  be  compiled  should  be 
the  main  program  whidi  utilizes  other  programming  units  to  perform 
a  task. 

d.  If  the  main  program  required  no  corrections  and  recompilations,  the 
next  step  is  to  invoke  the  Ada  linker  which  produces  an  executable 
program  by  putting  together  the  separate  components  of  the 
program.  To  link  the  compiled  program,  type  the  following  at  the 
prompt; 

A:\>bamp  try 

The  name  of  the  main  program  (in  this  case  "try")  is  the  only 
information  needed  by  the  linker.  An  executable  program  file  (given 
the  name  try.exe)  is  produced  by  the  linker. 

e.  To  run  the  executable  program,  type  the  name  of  the  file  (without  the 
extension)  at  the  prompt: 

A:\>try 


2.  To  practice  entering  and  compiling  a  program,  use  the  program  given  in 
your  Benjamin  textbook  on  page  2.  Pages  2-4  explain  the  actions  and 
statements  in  this  program. 


3.  Also  included  in  the  Ada  environment  on  the  machines  in  our  bcal  lab  is  an 
interactive  Shareware  Ada  tutor.  This  is  a  self-paced  introduction  to  Ada. 
[John  Herro,  The  interactive  Ada-Tutor,  Software  Innovations  Technology, 
1083  Mandarin  Drive  N.E..  Palm  Bay  FL.  32905-4706] 

To  access  this  tutorial  software  package,  type  the  following  sequence  of 
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commands  starting  at  the  DOS  C  driva: 

C:\>cdacla 
C:\ada>cd  adatutor 
C:\Bda\adatiitof>ada-tiitr 


ASSOCIATED  HANDOUTS- 

Description  of  Ada  lat)oratory  environment 
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Working  in  Ada  Environment 
In  Lab  104 


For  all  these  tasks,  start  at  the  DOS  prompt  (if  working  on  OS/2  machine,  go  to  DOS  Full 
Screen).  To  prepare  your  diskette  for  compiling  and  running  Ada  programs: 

1 .  Put  formatted  diskette  in  drive  A. 


2.  Change  directory  to  drive  A. 


3.  Type  "newiib"  at  the  prompt. 

A:\>newlib 

This  command  will  create  an  ADA.LIB  program  and  an  ADA.AUX  directory  on  your 
diskette.  This  command  creates  a  local  library  database  that  references  the 
standard  library  database  file  provided  by  the  compiler.  A  link  from  your  diskette 
back  to  the  Ada  compiler  in  the  C:\ADA  directory  is  also  established.  This 
command  has  to  be  done  only  once  for  a  diskette  unless  these  items  are  deleted 
from  the  disk. 


4.  To  type  in  a  program,  use  the  Turbo  Pascal  editor  which  can  be  accessed  from 
the  A:  drive  by  simply  typing  "turbo"  at  the  prompt. 

A:\>turbo 


5.  For  this  example,  let's  say  that  the  program  just  created  was  in  a  file  named 
Iry.ada”  and  the  name  of  the  main  program  (the  internal  name  of  the  program) 
was  "try".  To  compile  an  Ada  programming  unit,  type  the  following  at  the  prompt: 

A:\>ada  try.ada 

You  must  include  the  file  extension  \Rriien  compiling.  This  command  will  indicate, 
in  Its  screen  output,  the  line  number  and  type  of  error  for  any  compile  errors 
encountered  in  the  program.  The  Turbo  Pascal  editor  gives,  as  you  move  through 
a  program,  the  current  line  number  on  the  bottom  left  of  the  screen;  these  line 
numbers  are  in  agreement  with  the  line  numbers  given  by  the  compiler  on  error 
messages. 

All  programming  units  must  be  compiled  in  the  order  of  their  dependency.  The 
final  programming  unit  to  be  compiled  should  be  the  main  program  which  utilizes 
other  programming  units  to  perform  a  task. 
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6.  If  the  main  program  required  no  corrections  and  recompilations,  the  next  step  is 
to  invoke  the  Ada  iinker  which  produces  an  executable  program  by  putting  together 
the  separate  components  of  the  program.  To  link  the  compiled  program,  type  the 
following  at  the  prompt: 

A:\>lMimp  try 

The  name  of  the  main  program  (in  this  case  "try")  is  the  only  information  needed 
by  the  iinker.  An  executabie  program  file  (given  the  name  try.exe)  is  produced  by 
the  linker. 


7.  To  run  the  executabie  program,  type  the  name  of  the  file  (without  the  extension) 
at  the  prompt: 

A:\>try 


8.  Also  provided  on  the  computers  in  room  104  is  an  interactive  Ada  tutor.  To  access 
this  software  package,  type  the  following  sequence  of  commands  starting  at  the 
DOS  C  drive: 


C:\>cd  ada 
C:\ada>cd  adatutor 
C:\ada\adatutor>ada-tutr 
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LAB  NUMBER:  023 


TQElCiSIf  PR  LAB: 

Peer  reviews  ■  extended  project  through  preliminary  design 
Preliminary  design  review  presentation 

INSTRUCTIONAL  OBJECTIVEfS^: 

1 .  Preside  opportunity  for  mid-point  peer  review  of  extended  project  teams. 

2.  Students  present  preliminary  design  review  for  extended  proj^. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  028 

SET  UP.  WARM-UP: 

This  is  the  mid-point  of  the  extended  project.  We  want  to  consider  your  opinions 
in  assessing  the  project  to  this  point.  We  have  prepared  a  peer/self  evaluation 
instrument  and  will  be  administering  it  today,  prior  to  your  preliminary  design 
review  presentation. 

PROCEDURE: 

1.  HANDOUT  -  Peer/self  evaluation  forms 

Ask  each  student  to  complete  a  peer/self  evaluation  for  the  overall  project 
and  one  for  each  team  on  which  he/she  was  a  member. 

Stress  that  their  responses  are  confidential  and  will  be  seen  by  the 
instructor  only.  While  feedback  wilt  be  provided  to  individuals,  the 
confidentiality  of  responses  will  remain  strictly  confidential. 

2.  Introduce  the  preliminary  design  team  and  begin  the  review. 


ASSOCIATED  HANDOUTS: 

Oral  presentation  evaluation  form  (2) 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 


AS.SQCJATSP  HANDOUTS: 

Mid-point  peer/self  evaluation  forms  -  overall  project 
Mid-point  peer/self  evaluation  forms  -  individual  teams 
Oral  presentation  evaluation  form 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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THIRD  EYE  PROJECT  MID-POINT  EVALUATION 


Responses  are  confidential  and  will  be  seen  only  by  the  instructors.  Be  completely 
honest  in  rating  the  following  from  your  perspective.  In  the  scale  used,  UNS  represents 
unsatisfactory  and  EXC  represents  excellent.  Use  back  for  additional  comments. 


Configuration  management  plan  Configuration  manager 


BELOW 
UNS  AVG 

1 - 1 - 1 - 1- 

AVG 
- 1 - 

ABOVE 

AVG 

•1 - 1 - 1- 

EXC 

BELOW 

UNS  AVG 

1 - 1 - 1 - 1- 

ABOVE 

AVG  AVG  EXC 

- 1 - 1 - 1 - 1 - 1 

COMMENTS: 

COMMENTS: 

Requirements 

Users  manual 

BELOW 
UNS  AVG 

AVQ 

ABOVE 

AVG 

EXC 

BELOW 

UNS  AVG 

ABOVE 

AVG  AVG  EXC 

1  1  1  1 

COMMENTS: 

1 

1  1  1 

1"'  1""  "1  r 

COMMENTS: 

Test  Plan 

Preliminary  design 

BELOW 
UNS  AVG 

1 - 1 - 1 - 

AVG 
- 1 - 

ABOVE 

AVG 

•1 - 1 - 1- 

EXC 

BELOW 

UNS  AVG 

1 — 1 — 1 — 1- 

ABOVE 

AVG  AVG  EXC 

- 1 - 1 - 1 - 1 - 1 

COMMENTS: 

COMMENTS: 

Overall,  the  Third  Eye  team 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 
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THIRD  EYE  PROJECT  MID-POINT  EVALUATION 


TEAM: _  MEMBER: _ 

Complete  the  following  for  each  member  of  the  team,  including  yourself. 

in  COLUMN  A.  describe  his/her  contributions  to  the  project. 

In  COLUMN  B,  select  VS  (very  satisfied).  8  (satisfied),  D  (dissatisfied),  or  VD  (very 
dissatisfied)  to  fill  in  the  blank  in  the  statement  below. 


"1  am 

with  his/her  work  on  the  team." 

(A) 

(B) 

M  1  II  II 
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LAB  NUMBER:  024 

TQPICfSl  FOR  LAB: 

User  interface  presentation/review 
Test  plan  presentation/review 

INSTRUCTIONAL  QBJECHYS(S): 

1 .  User  interface  team  presents  users  manual  for  final  review. 

2.  Test  plan  team  presents  test  plans  for  final  review. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  029 

SET  UP.  WARM-UP: 

Remind  students  that  the  purpose  of  these  reviews  are  to  improve  the  item  under 
review.  All  participants  (developers,  customers,  and  other  reviewers)  have  a 
common  goal:  to  identify  issues  that  need  to  be  addressed. 

Remind  them  as  well  of  some  of  the  guidelines  for  reviews  that  have  been 
discussed  in  the  past.  Include:  (fijring  the  review  we  want  to  identify  problems,  not 
attempt  to  solve  them;  avoid  the  tendency  to  resist  change  or  be  defensive; 
remember  this  is  a  team  effort. 

Remind  them  to  note  any  issues  identifiMI  that  require  attention  and  to  follow  up 
on  the  issues  list  as  soon  as  possible. 

PROCEDURE 

1 .  Introduce  the  user  interface  team  and  begin  the  review. 

2.  introduce  the  test  plan  team  and  begin  the  review. 

ASSOCIATED  HANDOUTS: 

Oral  presentation  evaluation  form  (2) 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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LAB,  NUMBEB:  025 


TCy ICfS)  FOR  LAB: 

Resolution  of  outstanding  issues  from  last  semester 

IMSTRUCIIQNAL  QBilEttTiYE(S): 

1 .  Provide  issues  list  from  last  semester  assessments  of  extended  project. 

ASSOCIATBP  LSCTUR&.NUMBER: 

Lecture  031 

SET  UP.  WABMrUe: 

As  a  part  of  the  final  exam  last  semester,  students  were  asked  intKvidualiy  to 
carefully  review  all  of  the  project  deliverables  and  identify  problems  or  note 
questions  on  issues  that  they  did  not  understand.  A  composite  issues  list  has 
been  compiled  based  on  the  student  reviews  as  well  as  a  thorough  review  by  the 
instructors.  Teams  will  need  to  resolve  ail  of  these  issues  before  we  can  move  on 
to  detailed  design  and  implementation. 

PROCEDURE: 

1.  HANDOUT  >  Composite  issues  list 

Discuss  the  items  and  emphasize  that  they  need  to  be  addressed  and  all 
necessary  modifications  made.  Students  will  remain  on  their  teams  from 
last  semester.  Any  new  students  will  be  assigned  to  work  with  one  of  the 
teams  from  last  semester. 

2.  Give  teams  remainder  of  time  to  work  on  the  project. 

ASSOCIATED  HANDOUTS: 

Composite  issues  list 
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LAB  02ft 


T0EiC(8ll?QaiAB: 

Reofganiiatton  (rf  ext»fKtod  prefect 

INSIRUCTKm  QftiEgTIYE(S): 

1.  Roorganiziiion  of  txlBfidsd  prelect 

AS80CIATEP  USCTURE  NUMBER: 

Lecture  032 

SET  UP.  WARM-UP: 

Today  we  are  poing  to  reorganize  the  project  to  proceed  with  detailed  design. 
PROCEDURE: 

1.  Have  configuration  manc^jement  team  report  on  the  state  of  the  project 
artifacts,  induding  the  modifications  begun  in  the  preceding  lab. 

2.  HANDOUT  •  List  of  project  teams 

Distribute  and  discuss  the  role  and  responsibilities  of  each  team.  Explain 
that  during  this  semester  the  project  will  be  taken  through  implementation. 
The  teams  that  will  be  active  during  this  semester  are  configuration 
management,  detailed  design,  code  and  unit  test,  and  testing  (and  tools  if 
a  tools  team  is  included  in  the  project  organization). 

3.  NOTE:  Additional  discussion  on  the  project  organization  is  included  in  the 
Projects  section  of  this  packet,  in  the  paper  on  the  inverted  functional  matrix 
organization. 

Discuss  the  immediate  responsibiiities  of  the  project  teams  and  give  them 
the  remainder  of  the  class  to  work  on  the  project. 


ASSOCIATED  HANDOUTS: 
List  of  teams 
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EXTENDED  PROJECT  TEAMS 

Configuration  management 
Detailed  design 
Code  and  unit  test 
Testing 

Tools  (optional) 


im  NUMBER:  027 

TQPICrS)  fOaiAB: 

Nassi-ShneMerman  charts 
Preparation  for  detailed  design  review 

INSTRUCTIONAL  QBJECTiVEtS): 

1.  Construct  Nassi-Shneiderman  charts 

2.  Prepare  detailed  design  team  for  upcoming  review 

ASSQCJAT1D.LECI.UBE  NUMBEB: 

Lecture  033 

SET  UP.  WARM-UP: 

During  detailed  design  algorithms  must  be  designed  and  represented  in  order  to 
be  reviewed  and  then  to  be  coded.  We  have  chosen  Nassi-Shneiderman  charts 
to  represent  the  algorithms  of  detailed  design  in  the  extended  project.  The 
notation  was  introduced  in  the  previrxjs  lecture.  Today  we  are  going  to  give  you 
practice  in  developing  Nassi-Shneiderman  charts.  Then  we  will  talk  about  the 
upcoming  detailed  design  review. 

PRQCEQUBf: 

1.  Walkthrough  an  example  of  a  Nassi-Shn^derman  chart.  Select  an 
algorithm  with  which  students  are  familar;  e.g.,  select  a  sequential  or  bin^ 
search,  a  transaction  handler  for  a  checkbook  (to  handle  deposits, 
withdrawals,  or  inquiries),  or  Mynaitt  exercise  2,  page  236. 

2.  a.  Separate  students  into  their  current  teams  and  ask  each  to  develop 

a  Nassi-Shneiderman  chart  for  an  exchange  sort  algorithm  (or  some 
other  with  which  they  are  familiar).  Give  the  teams  10-15  minutes 
to  construct  a  solution,  remaining  available  for  questions  as  they 
work. 

b.  Review  the  solutions  with  the  whole  class. 

3.  Since  the  detailed  design  review  is  the  first  major  review  of  the  second 
semester,  the  instructor  should  take  a  few  minutes  to  discuss  reviews. 
Recall  that  the  predominant  method  of  design  evaluation  is  the  design 
review.  At  a  design  review,  either  preliminary  design  or  detailed  design, 
there  are  two  basic  questions  to  keep  in  mind. 

Does  the  design  fulfill  the  requirements? 

Does  the  design  meet  established  design  standards? 

Review  the  material  first  presented  in  Lab  006.  This  is  particularly  important 
if  there  are  any  students  in  the  class  who  were  not  in  the  first  semester. 
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4.  HANDOUT  -  Detailed  design  review  form 

Distribute  and  discuss  the  detailed  design  review  form.  This  will  be  used 
by  reviewers  to  provided  feedback  to  the  presenters. 

Remind  the  detailed  design  team  that  the  material  to  be  reviewed  must  be 
provided  to  reviewers  in  advance.  Make  arrangements  for  the  materials  to 
be  provided  to  the  instructors  for  cfoplication  and  then  made  available  to  the 
reviewers. 

ASSOCIATED  HANDOUTS: 

Detailed  design  review  form 
Suggestions  for  giving  and  oral  presentation 
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Detaited  Design  Review  Form 


Project  Name  : _ 

Reviewer  Name  : _ 

I.  High  Level  Issues 

A:  Requirements:  any  requirements  missed,  requirements  over-worked? 

B:  Design:  suggestions  for  Improvement  of  architecture  or  procedures;  other 

strategies 

C:  The  Design  fits  the  whole  specification  including  quality  standards  such  as 

flexibility,  friendliness,  efficiency,  and  cost  effective. 

II  Design  Deliverable  Details 

A:  Revised  Test  Plan:  items  over  tested  or  under-tested,  suggested  tests 

B:  Design  Model:  good  use  of  notation,  dear  model,  suggested  improvements 


III  Detailed  Design 

A:  Can  design  be  implemented  easily:  availability  of  adequate  programming 

and  testing  manpower.  Adequate  hardware  fadlities-computer,  data 
storage... 

B:  Is  the  design  programmable-  does  not  require  exotic  functions 

C:  Is  there  a  suggested  or  obvious  order  of  implementation  or  approximate 

times  for  the  development  of  and  description  of  the  production  relations 
between  the  modules.  What  is  the  order  of  need  for  equipment  required 
to  implement  the  design. 

D:  Comments  on  other  deliverables 
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I,AB  NUMBER:  028 


TQPIGIS)  P.QR  LAB: 

Detailed  design  review  presentation 

INSTRUCTIONAL  OBJECTIYSia: 

1 .  Students  present  detailed  design  review  for  extended  project. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  038 

SET  UP.  WARM-UP: 

As  was  (tiscussed  in  the  last  lab.  today's  detailed  design  review  is  very  important. 
You  want  to  assure  that  the  design  fulfills  the  requirements,  meets  standards,  and 
is  consistent  with  the  preliminary  design.  This  assurance  is  critical  since  the 
preliminary  design  is  the  base  on  which  your  implementation  will  rest.  Problems 
uncovered  will  be  much  easier  to  resolve  now  than  they  will  be  during 
implementation  or  system  testing. 

PRQC£g.UBE: 

1 .  Remind  the  detailed  design  team  that  they  should  note  any  issues  which 
arise  during  the  review.  Each  item  on  this  "issues  list"  must  be  addressed 
and  appropriate  modifications  made  where  needed.  The  issues  list  thus 
serves  as  action  item  checklist  for  the  team  as  they  address  the  issues. 

The  instructor  should  maintain  his/her  own  issues  list  as  a  means  of 
establishing  a  follow-up  procedure  to  assure  that  the  items  are  addressed. 

instructors  should  maintain  their  role  as  customer  as  much  as  possible, 
reverting  to  role  of  instructor  only  when  necessary  for  such  things  as 
maintaining  the  schedule,  reminding  participants  of  the  purpose  and/or 
ground  rules,  and  maintaining  order.  Critiques  should  be  saved  until  the 
next  lecture  or  lab. 

2.  Introduce  the  detailed  design  team  and  begin  the  review. 


ASSOCIATED  HANDOUTS: 

Oral  presentation  evaluation  form 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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LAB  NUMBER:  029 


TQPIC(S)  FQRJLAB: 

Feedback  on  detailed  design  review  presentation. 

(NSIRUCIIQNAL  QBJECTiyEfS): 

1 .  Provide  feedback  on  detailed  design  review  presentations. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  040 

SET  UP.  WARM-UP: 

At  the  last  lab  the  detailed  design  was  reviewed.  We  want  to  provide  you  with  our 
reactions  to  the  review  and  make  sure  all  issues  have  been  identified  and  are 
being  addressed. 

PROCEDURE: 

1 .  Provide  specific  feedback  on  the  detailed  design.  Specificaily  ask  about  the 
"issues  list"  which  the  detailed  design  team  should  have  compiled  during 
the  review.  (Use  your  own  issues  fist  as  a  check.)  Ask  how  each  item  was 
addressed  and  the  disposition  of  each. 

This  meeting  is  critical  to  baseline  the  detailed  design.  Teams  are  about  to 
begin  implementation  and  agreement  must  be  reached  on  what  is  to  be 
implemented. 

ASSOCIATED  HANDOUTS: 
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130 


LAB  NUMBER:  0 

IQElg(SlFQB  LAB: 

Code  inspections 

INSTRUCTIONAL  QBJECTIVBSh 

1 .  Understand  haw  to  conduct  a  code  inspection. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  041 

SET  UP.  WARM-UP: 

Reviews  have  been  used  throughout  the  software  development  phases  up  to  this 
point  as  a  software  quality  assurance  activity.  Reviews  will  continue  to  be  used 
in  the  implementation  phase.  Today  we  want  to  consider  code  reviews,  or  code 
inspections. 

PROCEDURE: 

1 .  Introduce  the  video-tape  provided  in  the  educational  materials  package  from 
the  Software  Engineering  Institute  [L.E.  Deimel,  "Scenes  from  Software 
Inspections.”  CMU/SEI-91-S].  The  package  includes  a  video-tape  "Scenes 
of  Software  inspections"  and  discussion  aids.  In  less  than  20  minutes, 
students  see  several  dramatizations  of  common  pitfalls  in  formal  reviews. 
The  presentation  makes  the  pitfalls  and  the  problems  they  generate  obvious 
to  the  students.  Each  dramatization  is  intended  to  be  followed  by  a 
discussion  of  how  to  avoid  these  pitfalls.  This  discussion  reduces  anxiety 
about  reviews  and  develops  an  appreciation  of  appropriate  review  roles  and 
behavior. 

2.  The  code  and  unit  test  team  will  be  required  to  conduct  code  inspections 
of  their  work  at  the  appropriate  time. 

ASSOCIATED  HANDOUTS: 
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LAB  NUMBER:  031 

TQPiC{S)F.QRLAB: 

Introduction  to  maintenance  project 
Team  organization  for  maintenance  project 
Maintenance  assignment  1 

INSTRUCTIONAL  OBJECTIVEfSV. 

1 .  Introduce  maintenance  project  and  project  organization. 

2.  Assign  maintenance  exercise  2. 

ASSOCiATED  LECTURE  NUMBER: 

Lecture  045 

SET  UP,  WARM-UP: 

in  practice  software  engineers  often  work  on  multiple  projects  simultaneously.  It 
is  not  unusual  that  while  a  development  project  is  underway,  maintenance  must 
be  performed  on  an  existing  system.  Today  we  are  going  to  begin  on  a 
maintenance  project  which  will  overlap  the  extended  project. 

PROCEDURE 

1 .  Discuss  the  organization  of  the  maintenance  project. 

a.  For  the  duration  of  the  maintenance  project  all  class  meetings, 
including  both  lecture  and  lab  time,  will  be  devoted  to  an  in-class 
maintenance  project.  We  want  to  prevent  you  from  working  on  this 
maintenance  project  outside  of  class.  Of  course  you  will  continue 
working  on  the  extended  project  outside  of  class  time. 

b.  HANDOUT  -  Maintenance  project  teams 

Discuss  the  chief  progrsmnmer  organization.  The  project  organization 
for  the  maintenance  project  will  be  chief-programmer  teams.  We 
have  identified  the  chief  programmers. 

2.  Handout  -  The  DASC  SofhA^re  System 

Introduce  the  DASC  system.  Give  an  overview  of  what  it  does  and  the 

documents  that  are  available. 

3.  Explain  that  the  DASC  system  works,  but  not  in  our  environment.  The 

maintenance  assignments  will  involve: 

a.  porting  it  to  our  environment; 

b.  testing  it  according  to  the  DASC  test  plan  and  test  data  provided, 
and  completing  Discrepancy  Reports  as  necessary; 

c.  performing  some  maintenance  (enhancement)  tasks  based  on 
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Change  Requests  to  be  provided. 


4.  HANDOUT  -  DASC  Maintenance  exercise  1 

Distribute  and  discuss  maintenance  exercise  1 .  Also  make  available  to 
each  team  DASC  documentation  including  the  users  manuai,  requirements 
document,  test  cases,  expected  results  for  test  cases,  and  discrepancy 
report  forms. 

ASSQCiATED  HANDOUTS: 

Rosters  for  maintenance  project  teams  (with  Chief  Programmers  identified) 
DASC  Maintenance  exercise  1  and  associated  materiais 
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DASC  Maint«nanc«  Exercise  1 


The  DASC  system  has  recently  been  installed  in  our  lab.  The  purpose  of  this 
maintenance  exercise  Is  to  run  DASC  on  a  test  suite  and  record  any  discrepancies  for 
consideration  by  a  Change  Control  Board.  The  test  suite  and  discrepancy  report  forms 
are  provided.  Specific  directions  for  completing  the  exercise  follow. 


1 .  Use  the  disks  provided.  Each  contains: 

a.  DASC  executable,  STYLE.CH,  in  root  directory. 

b.  test  suite,  in  subdirectory  TEST.  (The  test  suite  consists  of  a  collection  of 
Ada  programs  to  be  used  as  input  to  DASC.) 

c.  COMMANDL.TXT  file,  in  root  directory. 

d.  DASC  source  code,  in  root  directory.  (The  DASC  source  code  is  not 
needed  for  this  exercise.) 


2.  Execute  STYLE_CH  on  each  program  in  the  test  suite: 

a.  Prior  to  executing  STYLE_CH,  edit  COMMANDL.TXT  so  that  It  contains  the 
complete  path  name  of  the  test  program. 

b.  run  STYLE_CH.  WARNING:  DASC  always  gives  an  "unable  to  open" 

error  message.  Ignore  it. 


3.  For  each  test,  STYLE.CH  creates  two  output  report  files,  a  flaw  report 
(testprogname.FLW)  and  a  style  report  (testprogname.STY).  Compare  the  results 
of  these  reports  with  the  expected  results  distributed  and  file  a  discrepancy  report 
for  each  discrepancy  found. 
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iggiasi^oaiAB: 

Code  inepections 

INSTRUCTIONAL  OBJECTtVEfS): 

1 .  Code  and  unit  test  team  conducts  code  inspections. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  046 

SEI.UE.3flgABM-iiE: 


in  todays  lab  the  code  and  unit  test  team  is  going  to  conduct  code  inspections  of 
their  work.  We  will  simply  be  observers  during  this. 


PROCEDURE: 


1 .  The  code  and  unit  test  team  conducts  code  inspections.  The  other  teams 
are  given  this  time  to  work  on  their  parts  of  the  project.  The  instructors 
function  primarily  as  observers  and  intervene  in  the  code  inspections  only 
if  necessary. 

ASSQCIAieP  HANDOUTS: 
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TQPtCfS)  FOR  LAB: 

Feedback  on  Maintenance  exerdee  1 
Maintenance  exercise  2 


INSTRUCTIONAL  QBJECTiVEfSh- 

1.  Provide  feedback  on  niaintenance  exercise  1. 

2.  Assign  maintenanoe  exercise  2. 


SET  UP,  WARM-UP: 

The  first  maintenance  exercise  should  have  given  you  an  external  (user)  view  of 
the  DASC  system;  spedficaily.  the  system's  output  (flaw  and  style  rep^).  the 
user  interface,  and  the  types  of  "style  factors”  the  syitom  is  assessing.  It  should 
serve  as  a  nice  lead-in  to  the  next  DASC  maintenanoe  exercise  that  you  will  be 
given  today. 

PROCEDURE 

1.  Discuss  results  of  maintenance  exercise  1. 

2.  HANDOUT  -  DASC  maintenance  exercise  2 
HANDOUT  •  DASC  source  code 


Discuss  the  exercise.  We  are  providing  you  with  some  internal 
documentation  of  the  system  and  asking  you,  as  maintenance  teams,  to 
plan  needed  changes  due  to  the  attached  discrepancy  reports  and  change 
requests. 


ASSOCIATED  HANDOUTS: 

DASC  Maintenance  exercise  2  and  attachments 
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DASC  lialntMianc*  Exercise  2 


Attached  are  two  DASC  Discrepancy  Reports  and  one  DASC  Change  Request.  Each  of 
the  three  has  been  approved  by  the  Configuration  Control  Board. 

Provide  a  detailed  description  of  the  modifications  necessary  to  correct  the  problems. 
Specifically,  submit: 

a)  changes  to  the  design  documents  provided  with  this  exercise;  and 

b)  changes  to  the  source  code  provided  with  this  exercise. 

At  this  point  you  are  not  required  to  submit  plans  for  testing  the  system  after  the 
modifications  are  made. 


Attachments;  DASC  Discrepancy  Report  37 
DASC  Discrepancy  Report  42 
DASC  Change  Request  1 1 
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DASC  TEST  DISCREPANCY  REPORT  Rtport  No.:  ^ 

Originator  (Team):  3  Date:  8^/93 

Test  Case/Program:  All 
Description  of  Expected  Result: 


Description  of  Actual  Result: 

During  execution,  the  message  "file  cannot  be  opened"  is  always  displayed 
to  the  screen. 


Additional  Comments: 

The  extraneous  message  has  no  apparent  significance,  and  presently  users 
have  been  instructed  to  ignore  it 


RESOLUTION  (to  be  completed  by  CCB) 

_  Change  Required 

_  Waived  -  Describe  reasons  waived: 

X  Approved  For  Analysis 

_  Duplicate  Problem  -  Associated  Test  Discrepancy  Report  No(s): 

CM  Signature:  Date: 
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DASC  TEST  DISCREPANCY  REPORT 


Rtport  No.:  42 
Date;  8/7/93 


Originator  (Team):  3 

Test  Case/Program:  Teat  223 

Description  of  Expected  Result: 

If  the  COMMANDLTXT  Input  file  la  empty  or  contalna  the  name  of  a  non- 
exiatent  Ada  aourca  program,  DASC  ahouM  detect  thia  and  reapond  to  the 
uaer  In  aome  appropriate  manner. 

Description  of  Actual  Result: 

If  the  COMMANDLTXT  Input  file  Is  empty  or  contains  the  name  of  a  non¬ 
existent  Ada  source  program,  several  exceptions  are  raised  and  the  DASC 
system  tails  to  perform  properly.  See  attached  print-screen  of  DASC  display 
whenever  this  situation  occurs. 

Additional  Comments; 

RESOLUTION  (to  be  completed  by  CCB) 

_  Change  Required 

_  Waived  -  Describe  reasons  waived: 

X  Approved  For  Analysis 

_  Duplicate  Problem  •  Associated  Test  Discrepancy  Report  No(s); 

CM  Signature:  Date; 
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DASC  CHANGE  REQUEST 


Chano*  Raquast  No.:  Jl 
Date;  8/8/93 


Originator:  Bob  Ooraoy,  User  Support  (Oopt  3287) 

Change  Type:  JL  New  Feature  _  Cost  Reduction  _ Other  (describe) 

Change  description: 

Currently  DASC  expects  the  name  of  the  Ada  source  program  that  is  to  be 
processed  to  be  In  the  file  COMMANDLTXT.  Add  an  option  that  allows  the 
user  to  enter,  directly  from  the  keyboard  at  execution  time,  the  filename  of 
the  Ada  source  program  that  Is  to  be  processed. 

The  system  should  continue  to  support  the  use  of  the  COMMANDLTXT  file. 


CCB  Decision  (to  be  completed  by  CCB) 
X  Approved  As  Is 

_  Approved  With  Modification 

_  Waived 

Describe  reasons  waived  or  modification: 


CM  Signature: 


Date: 
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LAB  NUMBER:  034 

TQPICfS^  FOR  LAB: 

Feedback  on  Maintenance  exercise  2 
Maintenance  exercise  3 

iMSTRU.CTJQNAL  QBJECTiVB(S): 

1.  Provide  feedback  on  maintenance  exercise  2. 

2.  Assign  msuntenance  exercise  3. 

SET  UP.  WARM-UP: 

In  the  last  maintenance  exercise  you  responded  to  discrepancy  reports  and  a 
change  request  for  DASC.  Today  we  want  you  to  respond  to  plan  some 
modifications  to  enhance  the  system.  Again,  these  will  be  provided  in  the  form  of 
change  requests. 

PBQCEDURE 

1 .  Discuss  results  of  maintenance  exercise  2. 

2.  HANDOUT  -  DASC  maintenance  exercise  3 

Discuss  the  exercise. 

ASSOCIATED  HANDOUTS: 

DASC  Maintenance  exercise  3  and  attachments 
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OASC  liilntonanM  ExtreiM  3 


Plan  the  modifications  necessary  to  enhance  the  system  as  called  for  in  DASC  Change 
Requests  23  and  39. 

Submit  the  foiiowing  far  each  change  request. 

a)  Give  a  narrative  high-levei  description  of  two  distinct  solutions  to  the  problem. 

b)  For  each  of  the  solutions,  give  arguments  for  and  against. 

c)  For  the  solution  you  choose  as  best,  show: 

(1 )  the  changes  to  the  design  documents  provided;  and 

(2)  the  screen  layouts  for  any  user  interface  (Change  Request  23),  and  input 
file  specifications  (Change  Request  39);  and 

(3)  indicate  what  sections  of  the  source  code  have  to  be  changed  and  how. 


Att:  DASC  Change  Request  23 
DASC  Change  Request  39 
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OASC  CHANGE  REQUEST 


Changt  R«quMt  No.:  JO. 

Date;  8/10/93 


Originator:  Bob  Dorsey,  User  Support  (Dept  3287) 

Change  Type;  JL  New  Feature  _  Cost  Reduction  _  Other  (describe) 
Change  description: 

Modify  DASC  to  allow  screen  display  of  flaw  and  style  reports.  The  system 
should  ask  the  user  If  he/ahe  wants  to  see  a  display  of  the  flaw  report  If  so, 
the  flaw  report  should  be  displayed  on  the  screen  one  "screen-fuir'  at  a  time 
(like  the  DOS  more  command).  After  each  screen-full,  the  user  should  be  able 
to  request  the  next  screen-full  or  exit  Similarly,  a  display  of  the  style.report 
should  be  allowed. 


CCB  Decision  (to  be  (X)mpieted  by  CCB) 
X  Approved  As  Is 

_  Approved  With  Modification 

_  Waived 

Describe  reasons  waived  or  modification: 


CM  Signature; 


Date: 
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DASC  CHANGE  REQUEST  Chang*  Raqutst  No.:  M 

Originator:  Jodia  Mllosovlch,  Uaar  Support  (Dopt  3287)  Date:  8/1(V93 

Change  Type:  JL  New  Feature  _  Cost  Reduction  _  Other  (describe) 

Change  description: 

Modify  DASC  ao  that  tha  thraahold  valuaa  of  tha  quantHiabia  atyla  paramatars 
ara  read  from  am  input  fiia  rathar  than  baing  hard-codad  into  tha  sj^Mam.  TMs 
¥viii  aiiow  diffOrant  organizations  to  cuatomiza  tha  systam  mora  aaaiiy. 


CCB  Decision  (to  be  completed  by  CCB) 
X  Approved  As  Is 

_  Approved  With  Modification 

_  Waived 

Describe  reasons  waived  or  modification: 


CM  Signature: 


Date: 
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IQPiClS)  FOR  LAB: 

Final  peer/self  assessment  -  extended  project 
System  acceptance  test/review  •  extended  project 

INSTBUCTIONAL  OBJECTIVELS): 

1 .  Administer  final  peer/self  assessment  of  extended  project  teams. 

2.  Conduct  system  acceptance  test/review  for  extended  small  project. 

ASSOCIATED  LECTURE  NUMBER: 

SET  UP.  WARM-UP: 

As  we  have  been  ctoing  throughout  the  team  projects,  we  want  to  consider  your 
opinions  in  assessing  the  extended  project  teams.  All  of  the  project  deliverables 
are  due  today  and  all  that  remains  is  the  acceptance  test  and  addressing  any 
issues  that  arise  out  of  this  review.  Today  you  will  be  completing  a  peer/seif 
assessment  instrument  for  the  extended  project  and  for  the  teams  you  have  been 
working  on  in  the  latter  stages  of  the  projec*  Immediately  following  that  we  will 
conduct  the  acceptance  test  presentations. 

PROCEDURE: 

1 .  HANDOUT  -  Final  peer/self  evaluation  forms  for  extended  project. 

Ask  each  student  to  complete  a  peer/ss**  evaluation  form  for  the  teams  on 
which  he/she  participated  and  for  the  overall  project.  Stress  that  their 
responses  are  confidential  and  will  be  seen  by  the  instructor  only.  While 
composite  feedback  will  be  provided  to  individuals,  the  confidentiality  of 
responses  will  be  strictly  meuntained. 

ASSOCIATED  HANDOUTS: 

Peer/self  evaluation  forms  for  extended  project 
Oral  presentation  evaluation  form 

Material  to  be  reviewed  has  been  provided  to  reviewers  in  advance. 
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THIRD  EYE  •  END  OF  PROJECT  PEER  EVALUATION 


Responses  are  confidential  and  will  be  seen  only  by  the  instructors. 

1 .  Rate  the  following.  UNS  represents  unsatisfactory  and  EXC  represents  excellent. 


Configuration  management  plan 

BELOW  ABOVE 

UNS  AVG  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 


Test  Plan 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 


Preliminary  Design 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 


Code  and  unit  test 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVG  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 


Configuration  Management 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


Requirements 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 


Users  manual 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVG  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 


Detailed  design 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 


COMMENTS: 


Testing 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

COMMENTS: 


Overall,  the  Third  Eye  System 

BELOW  ABOVE 

UNS  AVQ  AVQ  AVQ  EXC 

I - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 


COMMENTS: 
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2.  Characterize  the  interactions  between  the  indicated  teams  using  the  following  scale 
by  circling  the  most  the  most  appropriate  descriptor. 

VN  s  yery  J^on>productive  A  «  Adequate  VP  >  Very  £roductive 
N  «  ^on-productive  P  «  £roductive 

a)  Preliminary  design  team  &  Detailed  design  team  —  VN  N  A  P  VP 

b)  Detailed  design  team  &  Code  and  unit  test  team  —  VN  N  A  P  VP 

c)  Detailed  design  team  &  Testing  team - VN  N  A  P  VP 

d)  Code  &  unit  test  team  &  Testing  team - VN  N  A  P  VP 

e)  Detailed  design  team  &  Configuration  manager - VN  N  A  P  VP 

f)  Code  and  unit  test  team  &  Configuration  manager  —  VN  N  A  P  VP 

g)  Testing  team  &  Configuration  manager - VN  N  A  P  VP 
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THIRD  EYE  -  END  OF  PROJECT  PEER  EVALUATION 


TEAM: _  MEMBER: _ 

Complete  the  following  for  each  member  of  the  team,  including  yourself. 

In  COLUMN  A.  describe  his/her  contributions  to  the  project. 

In  COLUMN  B.  select  VS  (very  satisfied),  S  (satisfied),  D  (dissatisfied),  or  VD  (very 
dissatisfied)  to  fili  in  the  blank  in  the  statement  below. 

"I  am _ with  his/her  work  on  the  team." 

(A)  (B) 

TEAlItJiEMBER  _ CQNTfllBUTIQM(8) _  SATISFACTION 
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4.  Imagine  that  $2000  in  bonuses  is  to  be  distributed  among  the  THIRD  EYE  Project  team 
members.  Half  of  it  ($1000)  is  to  be  distributed  based  on  the  intellectual  contribution  to  the 
project,  i.e.,  significant  ideas  and  solutions  contributed.  The  other  half  ($1000)  is  to  be 
distributed  based  on  amount  of  individual  effort  contributed  to  the  project. 

Distribute  the  bonuses.  If  vou  wish,  justify  each  of  the  assignments.  Be  very  specific;  list 
some  especially  significant  contributions  tor  which  the  team  member  should  be  proud  or  where 
the  project  was  made  more  or  less  difficult  because  of  it. 


$1000  $1000 

Protect  Member  Name  concepts  effort  JUSTIRCATION 
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LAB  NUMBER:  036 


TQPICrS)  FOR  LAB: 

Instructors'  assessmsnt  of  sxtondsd  projoct. 

INSTRUCTKm-flftlBfiTlVEffi): 

1.  Provide  assessment  of  extended  project. 

2.  Provide  assessment  of  individuai  team  members. 

ASSOCIATED  LECTURE  NUMBER: 

SET  UP.  WARM-UP: 

Recall  that  the  course  policies  explained  that  there  were  three  factors  to  be 
considered  in  your  individual  project  grades:  the  product  produced  by  the  team, 
peer  assessment  of  individual  contributions  to  the  team  effort,  and  the  instruclor(s)' 
assessment  of  individual  contributions.  Today  each  of  you  will  receive  a  copy  of 
our  assessment  of  your  project  with  a  team  project  grade  and  with  an  individual 
grade  for  your  contribution  to  the  prc^. 

PRQCEPURS: 

1 .  HANDOUT  •  Extended  project  evaluation 

Distribute  individuai  assessment  reports  containing  the  product  grade,  the 
individual  grade,  and  extended  comments  on  the  produ^ 

2.  Invite  teams  or  individuals  to  make  appointments  to  discuss  the 
assessments.  Stress  that  we  will  discuss  the  peer/self  assessments  with 
individuals  but  only  in  composite  terms;  oonfidendality  will  be  maintained. 

ASSOCIATED  HANDOUTS: 

Extended  project  evaluations 
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EXTENDED  PROJECT  EVALUATION:  THIRD  EYE  PROJECT 


TEAM  MEMBER: _ 

TEAM  PRODUCT  GRADE:  95  TEAM  MEMBER'S  GRADE: _ 


COMMENTS  ON  DEUVERED  Pff 


Mott  of  tho  following  commtntt  ptrtaln  to  th#  dtlivtrtd  and  damonstratad 
aoftwara  product  and  art  not  nacaaaarlly  raflaetiva  of  tha  tima  and/or  affort 
axpandad.  Thara  la  no  quaatlon  tha  tbna  and  affort  axpandad  by  tha  proiact  taam 
waa  auparlativa.  Ovarall,  wa  art  axtramaly  plaaaad  with  tha  amount  and  quality  of 
tha  work  of  tha  Third  Eya  pro|aet  taam.  Ilia  commanta  balow  ara  auggaatlona  for 
bnprovamant  and  ara  not  Intandad  to  datract  from  our  ovarall  aatiafbction  with  your 
work. 


OVERALL 

Problems  observed  with  the  delivered  product  include  the  following. 

1 .  User  interface  -  The  user  interface  appeared  to  have  "fallen  between  the  cracks" 
throughout  the  entire  project  and,  subsequently,  was  very  crude  in  the  final 
product. 

2.  Inconsistencies  exist  both  between  and  among  the  requirements,  preliminary 
design,  detailed  design,  and  code  documents.  These  fall  into  two  categories: 
first,  decisions  documented  by  one  team  not  being  followed  by  another,  and 
second,  changes  made  by  one  team  not  being  reflected  (updated)  in  earlier 
documents. 

3.  Problems  with  filters  3  and  4  were  evident  in  the  acceptance  test.  In  filter  3,  the 
user  selection  of  specific  procedures/functions  for  further  evaluation  was 
cumbersome.  Simiiarly  the  results  of  filter  4  needed  improvement  (e.g.  results 
unclear,  "phantom”  functions/procedures, ...). 


CONRGURATION  MANAGEMENT 

The  configuration  management  plan  was  feasible  and  complete.  Its  implementation 
was  visible  and  worked  well  under  the  drcumstanoes.  Good  control  mechanisms 
("manilla  envelope  system”  in  lab,  and  memos  summarizing  approved  changes  and 
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new  baselines)  were  developed  and  well-managed,  but  unfortunately  are  not 
documented  in  the  configuration  management  plan.  The  final  build  (padtaging)  of 
the  Third  Eye  project  was  excellent.  One  suggestion  for  improvement  would  be  a 
better  method  for  the  reader  to  access  documents  in  the  configuration  management 
plan  (perhaps  global  page  numbering  or  labeling  and  numbering  within  appendices). 
The  modification  history  was  inconsistent  in  documents  (e.g.  chronologically  fonvatd 
in  some  documents,  backward  in  others). 


REQUIREMENTS 

The  requirements  for  this  project  were  difficult  to  pin  down  and  overall  a  pretty  good 
job  was  done  and  the  requirements  were  complete  and  appropriate.  As  the  project 
progressed  and  requirements  changed,  the  changes  were  not  always  made  in  the 
requirements  documents.  For  example  the  data  dictionary  was  not  updated;  nor  was 
the  narrative  description  (also  has  a  couple  of  typos).  Important  changes  to  the  non¬ 
functional  requirements  were  made  in  the  requirements  list  but  the  modifications  are 
not  clearly  traceable  through  the  modification  history  (e.g.  references  to  RQ1 ,  RQ 
2,  etc).  The  process  specifications  of  ^e  structured  analysis  model  were  helpful  to 
subsequent  life-cycle  teams. 


TEST  PLAN 

The  test  plan  was  complete  and  well  o^anized,  and  appropriate  detail  was  provided. 
It  provided  a  solid  framework  for  the  testing  team  to  later  use.  It  is  cumbersome  to 
integrate  all  of  the  filled-out  forms  (hard  to  trace  what  is  done). 


USER  MANUAL 

The  user  manual  format  and  first  draft  were  excellent,  but  the  final  manual  does  not 
reflect  the  current  system. 


PRELIMINARY  DESIGN 

Overall  a  good  job  was  done  though  there  are  some  inconsistencies  in  the 
preliminary  design  as  well  as  between  preliminary  design  and  detailed  design.  The 
object  diagram  of  the  object  model  shows  inheritance  from  the  class  Filter  to  the 

subclasses  Filter  1 . Filter  8.  yet  it  doesnl  exist  (the  relationship  should  be  shown 

as  an  aggregation);  attributes  were  removed  from  the  filters  and  we  asked  that  they 
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continue  to  be  shown;  without  attributes  there  is  no  information  to  be  found  when  the 
filters  are  called  by  the  summary  report.  The  Ada  specifications  are  inconsistent 
with  the  object  dictionary  (e.g.  Summary  Report  depicted  as  reading  filters  but  the 
filters  don't  hold  the  values;  also  confusion  with  Print  Report  File). 


DETAILED  DESIGN 

As  with  preliminary  design,  overall  a  good  job  was  done  though  there  are  some 
inconsistencies  in  the  detailed  design  as  well  as  between  detailed  design  and 
preliminary  design  (e.g.  Summary  report  output  file)  and  between  detailed  design 
and  coding.  The  output  file  for  summary  report  file  structure  is  missing;  Filter  PD-4 
will  not  work  as  specified;  there  needs  to  be  two  subprograms  named  to  be 
compared. 


CODING 

Overall  a  good  job  was  done,  particularly  considering  the  time  constraints  and 
resource  problems.  There  are  inconsistencies  between  detailed  design  and  the 
source  code  (e.g.  summary  report).  The  Ada  standards  were  not  adhered  to 
consistently. 
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LAB  NUMBER:  037 


TOPtCiS)  FQR  LAB: 

Function  points 

INSTRUCTIONAL  OBJECTIVE(S): 

1.  Be  able  to  estimate  resources  for  a  project  based  on  function  points 
analysis. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  049 

SET  UP.  WARM-UP: 

During  the  earlier  lecture  we  discussed  COCOMO  and  function  points  analysis  as 
methods  to  estimate  resources  (time  to  develop,  personnel  needed  at  various 
phases)  needed  for  a  project.  The  COCOMO  model  relies  on  a  single 
independent  variable,  estimated  lines  of  code,  to  derive  its  estimates.  Function 
points  analysis  provides  a  means  of  estimating  the  lines  of  code  based  on  the 
requirements  of  the  system  and  the  complexity  of  its  development.  Today  we're 
going  to  have  you  estimate  lines  of  code  for  the  extended  project  using  function 
points  analysis. 

PROCEDURE: 

1.  Begin  by  considering  only  the  user  inputs  for  the  extended  project.  Lead 
the  class  through  the  completion  of  function  points  worksheets,  identify  the 
number  of  user  inputs  and  then  discuss  moc^ng  these  using  the  technical 
complexity  factors. 

2.  HANDOUT  •  Function  points  work  sheets  (see  lecture  049). 

Divide  the  class  into  groups  of  3-5  students  each.  Ask  each  group  to 
repeat  the  exercise  above  with  each  group  assigned  one  of  the  following: 

a.  user  outputs; 

b.  user  inquiries; 

c.  files; 

d.  external  interfaces. 

NOTE:  This  is  probably  best  done  as  a  group  exercise  outside  of  class. 

3.  Collect  the  group  results  and  compute  the  total  number  of  function  points 
for  the  extended  project.  Us  this  to  derive  the  estimated  number  of  lines  of 
source  code. 

4.  Consider  how  this  estimate  compares  with  the  actual  lines  of  code  for  the 
extended  project.  Discuss  reasons  for  the  discrepancy  between  the 
estimated  and  actual  lines  of  code. 

ASSOCIATED  HANDOUTS: 

Function  points  work  sheets  (see  lecture  049). 
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LAB  NUMBER:  038 


TOPICfS)  FOR  LAB: 

Ethical  issues  and  professionalism 

INSTRUCTIONAL  OBJECTIVEfS): 

1 .  Be  able  to  identify  ethical  issues  in  software  engineering 

2.  Understand  professional  responsibilities  of  software  developers 

3.  Be  able  to  analyze  ethical  scenarios  to  identify  the  ethical  issues,  discover 
applicable  ethical  principles,  and  make  ethical  decisions. 

ASSOCIATED  LECTURE  NUMBER: 

Lecture  050 

SET  UP.  WARM-UP: 

NOTES  TO  INSTRUCTOR: 

1 .  Several  laboratories  concerning  ethical  issues  are  described.  These  labs, 
as  well  as  lectures  on  ethical  issues  and  professionalism,  are  appropriate 
at  various  times  during  the  two-semester  course.  Placing  them  in  the  last 
several  weeks  of  the  second  semester  takes  advantage  of  the  accumulated 
student  project  experience  and  serves  as  a  capstone.  Students  are  less 
likely  to  be  preoccupied  with  project  work  at  this  point  and  may  be  more 
attentive  to  the  topic.  Introducing  this  material  immediately  after  completion 
of  the  small  projects  or  at  the  end  of  preliminary  design  of  the  extended 
project  (either  at  the  end  of  first  semester  or  the  beginning  of  the  second 
semester)  also  has  merit.  At  these  points  students  have  had  meaningful 
project  experience  but  plenty  of  project  work  remains.  Introducing  the  topic 
here  with  followup  throughout  the  second  semester  will  cause  students  to 
think  about  ethical  issues  and  professionalism  during  their  subsequent 
project  work.  Yet  another  option  is  to  introduce  this  material  during  the 
second  semester  coincident  with  the  extended  project  reorganization  as 
detailed  design  completes  and  implementation  activities  begin. 

2.  Ethical  Decision  Making  and  information  Technology  by  Kaliman  and  Grillo 
(McGraw-Hill,  1993)  and  the  accompanying  instructor's  manual  are  excellent 
resources  for  analyzing  ethical  issues.  They  present  a  four-step  analysis 
process  and  a  worksheet  for  making  appropriate  decisions.  We  highly 
recommend  this  as  a  supplementary  textbook.  If  adopted  then  the 
worksheets  and  other  supporting  materials  may  be  reproduced  for  use  with 
the  textbook.  Several  of  the  Is^ratory  exercises  described  below  assume 
that  the  Kallman/Grillo  textbook  has  been  adopted. 

PROCEDURE  and  ASSOCIATED  HANDOUTS: 

Attached  are  Procedure  and  Associated  Handouts  sections  for  a  number  of 
suggested  laboratories.  These  are  referred  to  as  038-1 ,  038-2,  etc. 
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PROCEDURE:  038-1 


NOTE;  This  can  be  done  as  an  individual  exercise  or  a  group  exercise 
involving  the  current  project  teams. 

It  is  assumed  that  the  associated  handouts  listed  below  have  already 
been  assigned  as  outside  reading. 

1 .  Describe  the  following.  Some  software  development  companies  have  been 
known  to  develop  a  first  version  of  a  software  package  and  begin  selling  it 
even  though  they  are  aware  that  it  still  has  some  "bugs".  They  expect  that 
users  will  find  and  report  bugs  as  well  as  make  other  suggestions  for 
improving  the  product.  The  software  development  company  plans  to  use 
these  bug  reports  (complaints)  and  other  suggestions  to  improve  the 
product  for  "version  1.1". 

2.  Ask  whether  any  of  the  Cases  in  the  article  Using  the  New  ACM  Code  of 
Ethics  in  Decision  Making  address  this  issue?  Expect  that  students  will 
recognize  the  similarities  with  Case  6. 

3.  Ask  students  to  analyze  the  scenario  (as  in  done  in  the  article)  and  cite 
specific  imperatives  in  the  ACM  Code  of  Ethics  and  Professional  Conduct 
that  are  applicable. 

4.  If  this  was  done  by  teams,  have  each  team  report  on  its  analysis. 

ASSOCIATED  HANDOUTS: 

ACM  Code  of  Ethics  and  Professional  Conduct 

Article:  "Using  the  New  Acm  Code  of  Ethics  in  Decision  Making",  by 

Anderson,  Johnson,  Gotterbam,  and  Perrolle.  Communications  of 
the  ACM.  Feb  1993 
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PRCXSEDURE:  038-2 


NOTE:  This  can  be  done  as  an  individual  exercise  or  a  group  exercise 

involving  the  current  project  teams. 

It  is  assumed  that  the  associated  handouts  listed  below  have  already 
been  assigned  as  outside  reading. 


1. 


Describe  the  following  scenario  adapted  from  Ethical  Conflicts  in  Information 
and  Computer  Science.  Technology,  and  Business  by  Parker,  D.,  Swope. 
S.,  and  Baker,  B.  (Wellesley,  MA:  QED  Information  lienees,  1990). 


The  ETSU  Software  Corporation  is  developing  the  hardware  and  software 
for  a  computerized  voting  machine  under  a  contract  with  the  Freedom 
Tabulating  Company  (FTC),  which  is  marketing  the  system.  FTC  has 
persuaded  several  cities  and  states  to  purchase  the  system  for  use  in  the 
next  elections.  Sandy  Smith,  a  software  engineer  with  ETSU,  is  aware  of 
problems  in  the  hardware/software  interface  that  are  likely  to  cause  the 
machine  to  miscount  approximately  one-half  of  one  percent  (0.5%)  of  the 
time.  Sandy  reports  this  back  to  the  software  project  director,  who 
responds  "that's  a  hardware  problem". 


2.  Ask  whether  any  of  the  Cases  in  the  article  Using  the  New  ACM  Code  of 
Ethics  in  Decision  Making  address  this  issue? 


3.  a.  Ask  students  to  analyze  the  scenario  (as  is  in  done  in  the  article) 
and  cite  specific  imperatives  in  the  ACM  Code  of  Ethics  and 
Professional  Conduct  that  are  applicable, 
b.  What  responsibility,  if  any,  does  Sandy  have  for  the  ultimate  use  of 
the  system?  Cite  the  specific  aspects  of  the  code  that  apply. 


4.  If  this  was  done  by  teams,  have  each  team  report  on  its  analysis. 


ASSOCIATED  HANDOUTS: 

ACM  Code  of  Ethics  and  Professional  Conduct 

Article:  "Using  the  New  Acm  Code  of  Ethics  in  Decision  Making",  by 

Anderson,  Johnson,  Gotterbarn,  and  Perrolle.  Communications  of 
the  ACM.  Feb  1993 


3 


Lab  038 


PRCX^EDURE:  038-3 


NOTE:  This  can  be  done  as  an  individual  exercise  or  a  group  exercise 

involving  the  current  project  teams. 

It  is  assumed  that  the  associated  handouts  listed  below  have  already 
been  assigned  as  outside  reading. 

1.  Describe  the  following.  K.  Kuhn  is  a  software  engineer  for  SECURE 
Software.  SECURE  has  developed  a  software  system  that  has  been 
successfully  tested  and  is  now  being  used  in  several  states.  The  system 
enables  the  criminal  justice  system  to  monitor  low-risk  prisoners  and  has 
helped  solve  the  "overcrowded  prison”  problem  (by  releasing  low-risk 
offenders  but  monitoring  their  movements  and  the  people  they  associate 
with,  and  by  enforcing  curfews).  SECURE  has  now  been  approached  by 
the  government  of  a  foreign  country  and  asked  to  design  a  system  based 
on  that  used  in  the  United  States  but  with  a  number  of  changes.  K.  Kuhn 
has  raised  concerns  with  SECURE  that  the  foreign  government  intends  to 
use  the  requested  system  to  more  effectively  and  efficiently  manage  and 
preserve  their  oppressive  practices  towards  their  citizens.  Kuhn's 
management  takes  the  position  that  it  is  none  of  their  business  how  the 
foreign  government  uses  the  system. 

2.  Ask  whether  any  of  the  Cases  in  the  article  Using  the  New  ACM  Code  of 
Ethics  in  Decision  Making  address  this  issue? 

3.  a.  Ask  students  to  analyze  the  scenario  (as  in  done  in  the  article)  and 

cite  specific  imperatives  in  the  ACM  Code  of  Ethics  and  Professional 
Conduct  that  are  applicable. 

b.  Kuhn  is  considering  many  actions;  doing  nothing;  refusing  to  work  on 
the  project;  resigning;  expressing  the  concerns  to  higher 
management;  informing  the  press  of  the  foreign  government's  plans 
for  the  system  and  SECURE's  role  in  it;  and  contacting  the 
Congressional  representative  for  the  district.  What  guidance,  if  any, 
does  the  proposed  ACM  Code  of  Ethics  and  Professional  Conduct 
provide  Kuhn?  In  your  answer,  cite  the  specific  sections  of  the  code 
that  apply. 

c.  What  responsibility,  if  any,  does  Kuhn  have  for  the  ultimate  use  of  the 
system?  Cite  the  specific  aspects  of  the  code  that  apply. 


4.  If  this  was  done  by  teams,  have  each  team  report  on  its  analysis. 


ASSOCIATED  HANDOUTS: 

ACM  Code  of  Ethics  and  Professional  Conduct 

Article:  "Using  the  New  Acm  Code  of  Ethics  In  Decision  Making",  by  Anderson, 
Johnson,  Qotterbam,  and  Perroile.  Communications  of  the  ACM.  Feb  1993 
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PROCEDURE:  038-4 


NOTE:  This  can  be  done  as  an  individuai  exercise  or  a  group  exercise  involving  the 
current  project  teams. 

It  is  assumed  that  the  associated  handouts  listed  below  have  already  been 
assigned  as  outside  reading. 

1 .  Describe  the  following.  According  to  the  Compliance  with  Code  section,  each 
ACM  member  agrees  to  personally  uphold  the  principles  of  the  code.  In  your 
opinion,  does  the  code  place  any  responsibility  on  members  regarding  violations 
of  the  code  by  other  members?  If  so.  what  is  the  responsibility?  If  not,  do  you 
think  this  is  a  serious  omission  in  the  code? 

2.  If  this  was  done  by  teams,  have  each  team  report  on  its  analysis. 

ASSO.CIAIEP  HAND, PUIS: 

ACM  Code  of  Ethics  and  Professional  Conduct 

Article:  "Using  the  New  Acm  Code  of  Ethics  in  Decision  Making",  by  Anderson, 
Johnson,  Gotterbam,  and  Perroile.  Communications  of  the  ACM.  Feb  1993 
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PROCEDURE:  038-5 


ASSOCIATED  HANDOUTS: 

ACM  Code  of  Ethics  and  Professional  Conduct 

Article:  Usinp  the  New  Acm  Code  of  Ethics  in  Decision  Making  by  Anderson. 

Johnson.  Gk>tterbam,  and  Perroiie.  Communications  of  the  ACM.  Feb  1993 

Kailman's  Four  Step  Analysis  Process 

Case  Worksheets  for  analysis  of  ethicai  scenarios  (Kallman) 

1 .  HANDOUT  •  Kailman's  Four  Step  Analysis  Process 

Discuss  Kailman's  process  to  andyze  an  ethical  situation.  Lead  the  class 
through  the  analysis  of  a  scenario  as  an  example. 

2.  HANDOUT  -  Case  Worksheets  for  analysis  of  ethical  scenarios  (Kallman) 
Describe  an  ethical  scenario  (e.g.  any  of  those  used  in  Procedures  038-1. 038-2. 
038-3.  038-4.  or  one  of  your  own.) 

3.  Ask  students  individually  to  follow  Kailman's  four-step  analysis  process  to 
complete  a  worksheet  for  the  scenario.  While  this  can  be  done  in  class,  we 
prefer  to  provide  the  worksheet  and  scenario  to  the  class  in  advance  arKf 
students  are  expected  to  come  to  the  lab  with  the  worksheet  completed. 

4.  Divide  students  into  groups  consisting  of  the  current  project  teams.  Give  the 
group  20-30  minutes  to  analyze  the  scenario  as  a  group  and  complete  a  group 
(consensus)  worksheet.  (Note  -  Kailman's  textbook.  Ethical  Decision  Making  and 
Information  Technology  and  the  accompanying  instructor's  manual  has 
suggestions  for  conducting  such  exercises.) 

5.  Have  each  team  report  on  its  analysis. 

ASSOCIATED  HANDPU.TS: 

ACM  Code  of  Ethics  and  Professional  Conduct 

Article:  Using  the  New  Acm  Code  of  Ethics  in  Decision  Making  by  Anderson. 

Johnson,  (aotterbam.  and  Perroiie.  Communications  of  the  ACM.  Feb  1993 

**  Kallman/Grillo  Four  Step  Analysis  Process 

**  Kallman/Grillo  Case  Worksheets  for  analysis  of  ethical  scenarios 


-  see  Note  2  In  Lab  SET  UP.  WARM-UP  section 
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ACM  Code  of  Ethics  and  Professional  Conduct  * 


Preamble.  Commitment  to  ethical  professional  conduct  is  expected  of  every  member 
(voting  members,  associate  members,  and  student  members)  of  the  Association  for 
Computing  Machinery  (ACM). 

This  Code,  consisting  of  24  imperatives  formulated  as  statements  of  personal 
responsibility,  identifies  the  elements  of  such  a  commitment.  It  contains  many,  but  not  all, 
issues  professionals  are  likely  to  face.  Section  1  outlines  fundamental  ethical 
considerations,  while  Section  2  addresses  additional,  more  specific  considerations  of 
professional  conduct.  Statements  in  Section  3  pertain  more  spedficaliy  to  individuals  who 
have  a  leadership  role,  whether  in  the  workplace  or  in  a  volunteer  capacity  such  as  with 
organizations  like  ACM.  Principles  involving  compliance  with  this  Code  are  given  in 
Section  4. 

The  Code  shall  be  supplemented  by  a  set  of  Guidelines,  which  provide  explanation 
to  assist  members  in  dealing  with  the  various  issues  contained  in  the  Code.  It  is 
expected  that  the  Guidelines  will  be  changed  more  frequently  than  the  Code. 

The  Code  and  its  supplemented  Guidelines  are  intended  to  serve  as  a  basis  for 
ethical  decision  making  in  the  conduct  of  professional  work.  Secondarily,  they  may  serve 
as  a  basis  for  judging  the  merit  of  a  formal  complaint  pertaining  to  violation  of  professional 
ethical  standards. 

It  should  be  noted  that  although  computing  is  not  mentioned  in  the  imperatives  of 
section  1 .0,  the  Code  is  concerned  with  how  these  fundamental  imperatives  apply  to 
one's  conduct  as  a  computing  professional.  These  imperatives  are  express^  in  a 
general  form  to  emphasize  that  ethical  principles  which  apply  to  computer  ethics  are 
derived  from  more  general  ethical  principles. 

It  is  understood  that  some  words  and  phrases  in  a  code  of  ethics  are  subject  to 
varying  interpretations,  and  that  any  ethical  principle  may  conflict  with  other  ethical 
principles  in  specific  situations.  Questions  related  to  ethical  conflicts  can  best  be 
answered  by  thoughtful  consideration  of  fundamental  principles,  rather  than  reliance  on 
detailed  regulations. 


1.  GENERAL  MORAL  IMPERATIVES.  As  an  ACM  member  I  will . . . 

1 .1  Contribute  to  society  and  human  well-being. 

1 .2  Avoid  harm  to  others. 

1 .3  Be  honest  and  trustworthy. 

1.4  Be  fair  and  take  action  not  to  discriminate. 

1 .5  Honor  property  rights  including  copyrights  and  patents. 

1 .6  Give  proper  credit  for  intellectual  property. 

1 .7  Respect  the  privacy  of  others. 

1 .8  Honor  confidentiality. 


*  Adopted  by  ACM  Council  10/16/92. 
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2.  MORE  SPECIFIC  PROFESSIONAL  RESPONSIBILITIES.  As  an  ACM  computing 
professional  I  will . . . 

2.1  Strive  to  achieve  the  highest  quality,  effectiveness  and  dignity  in  both  the  prooess  and 
products  of  professional  work. 

2.2  Acquire  and  maintain  professional  competence. 

2.3  Know  and  respect  existing  laws  pertaining  to  professional  work. 

2.4  Accept  and  provide  appropriate  professional  review. 

2.5  Give  comprehensive  and  thorough  evaluations  of  computer  systems  and  their 
impacts,  including  analysis  of  possible  risks. 

2.6  Honor  contracts,  agreements,  and  assigned  responsibilities. 

2.7  improve  public  understanding  of  computing  and  its  consequences 

2.8  Access  computing  and  communication  resources  only  when  authorized  to  do  so. 

3.  ORGANIZATIONAL  LEADERSHIP  IMPERATIVES.  As  an  ACM  member  and  an 

organizational  leader,  I  will . 

3.1  Articulate  soda!  responsibilities  of  members  of  an  organizational  unit  and  encourage 
full  acceptance  of  those  responsibilities. 

3.2  Manage  personnel  and  resources  to  design  and  build  infonnation  systems  that 
enhance  the  quality  of  working  life. 

3.3  Acknowledge  and  support  proper  and  autiiorized  uses  of  an  organization's  computing 
and  communication  resources. 

3.4  Ensure  that  users  and  those  who  \Mli  be  affected  by  a  system  have  their  needs 
clearly  articulated  during  the  assessment  and  design  of  requirements;  later  the 
system  must  be  validated  to  meet  requirements. 

3.5  Articulate  and  support  policies  that  protect  the  dignity  of  users  and  others  affected  by 
a  computing  system. 

3.6  Create  opportunities  for  members  of  the  organization  to  learn  the  principles  and 
limitations  of  computer  systems. 

4.  COMPLIANCE  WITH  THE  CODE.  As  an  ACM  member.  I  will _ 

4.1  Uphold  and  promote  the  principles  of  this  Code. 

4.2  Treat  violations  of  this  code  as  inconsistent  with  membership  in  the  ACM. 
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QUIDEUNE8 


1.  GENERAL  MORAL  IMPERATIVES.  As  an  ACM  member  I  will .... 

1.1  Contribute  to  society  and  human  well-being. 

This  principle  concerning  the  quality  of  life  of  all  people  affirms  an  obligation  to  protect 
fundamental  human  rights  and  to  respect  the  diversity  of  ail  cultures.  An  essential  aim  of 
computing  professionals  is  to  minimize  negative  consequences  of  computing  systems, 
including  threats  to  health  and  safety.  When  designing  or  implementing  systems, 
computing  professionals  must  attempt  to  ensure  that  the  products  of  their  efforts  will  be 
used  in  socially  responsible  ways,  will  meet  social  needs,  and  will  avoid  harmful 
effects  to  health  and  welfare. 

In  addition  to  a  safe  sodal  environment,  human  well-being  includes  a  safe  natural 
environment.  Therefore,  computing  professionals  who  design  and  develop  systems  must 
be  alert  to,  and  make  others  aware  of,  any  potential  damage  to  the  local  or  global 
environment. 

1 .2  Avoid  harm  to  others. 

"Harm"  means  injury  or  negative  consequences,  such  as  undesirable  loss  of  information, 
loss  of  property,  property  damage,  or  unwanted  environmental  impacts.  This  prindpie 
prohibits  use  of  computing  technology  in  ways  that  result  in  harm  to  any  of  the  following; 
users,  the  general  public,  employees,  employers.  Harmful  actions  include  intentional 
destruction  or  modification  of  files  and  programs  leading  to  serious  loss  of  resources  or 
unnecessary  expenditure  of  human  resources  such  as  the  time  and  effort  required  to 
purge  systems  of  "computer  viruses." 

Well-intended  actions,  including  those  that  accomplish  assigned  duties,  may  lead  to 
harm  unexpectedly.  In  such  an  event  the  responsible  person  or  persons  are  obligated  to 
undo  or  mitigate  the  negative  consequences  as  mu^  as  possible.  One  way  to  avoid 
unintentional  harm  is  to  carefully  consider  potential  impacts  on  all  those  affected  by 
decisions  made  during  design  and  implementation. 

To  minimize  the  possibility  of  indirectly  homing  others,  computing  professionals  must 
minimize  malfunctions  by  following  generally  accepted  standards  for  system  design  and 
testing.  Furthermore,  it  is  often  necessary  to  assess  the  social  consequences  of  systems 
to  project  the  likelihood  of  any  serious  harm  to  others.  If  system  features  are 
misrepresented  to  users,  coworkers,  or  superviscHS,  the  individual  computing  professional 
is  responsible  for  any  resulting  injury. 

In  the  work  environment  the  computing  professional  has  the  additional  obligation  to 
report  any  signs  of  system  dangers  that  might  result  in  serious  personal  or  social 
damage.  If  one's  superiors  do  not  act  to  curtail  or  mitigate  such  dangers,  it  may  be 
necessary  to  "blow  the  whistle"  to  help  correct  the  problem  or  reduce  the  risk.  However, 
capricious  or  misguided  reporting  of  violations  can,  itself,  be  harmful.  Before  reporting 
violations,  all  relevant  aspe^  of  the  incident  must  be  thoroughly  assessed,  in  particular, 
the  assessment  of  risk  and  responsibility  must  be  credible.  It  is  suggested  that  advice  be 
sought  from  other  computing  professionals.  See  principle  2.5  regarding  thorough 
evaluations. 
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1 .3  Be  honest  and  trustworthy. 

Honesty  is  an  essential  component  of  trust.  Without  trust  an  organization  cannot  function 
effectively.  The  honest  computing  professional  will  not  make  deliberately  false  or 
deceptive  claims  about  a  system  or  s)^m  design,  but  will  instead  provide  full  disclosure 
of  all  pertinent  system  limitations  and  problems. 

A  computer  professional  has  a  duty  to  be  honest  about  his  or  her  own  qualifications, 
and  about  any  circumstances  that  might  lead  to  conflicts  of  interest. 

Membership  in  volunteer  organizations  such  as  ACM  may  at  times  place  individuals 
in  situations  where  their  statements  or  actions  could  be  interpreted  as  carrying  the 
"weight"  of  a  larger  group  of  professionals.  An  ACM  member  will  exercise  care  to  not 
misrepresent  ACM  or  positions  and  policies  of  ACM  or  any  ACM  units. 

1 .4  Be  fair  and  take  action  not  to  discriminate. 

The  values  of  equality,  tolerance,  respect  for  others,  and  the  principles  of  equal  justice 
govern  this  imperative.  Discrimination  on  the  basis  of  race,  sex,  religion,  age,  disability, 
national  origin,  or  other  such  factors  is  an  explicit  violation  of  ACM  policy  and  will  not  to 
tolerated. 

Inequities  between  different  groups  of  people  may  result  from  the  use  or  misuse  of 
information  and  technology.  In  a  fair  society  .all  individuals  would  have  equal  opportunity 
to  participate  in,  or  benefit  from,  the  use  of  computer  resources  regardless  of  race,  sex. 
religion,  age.  disability,  national  origin  or  other  such  similar  factors.  However,  these  ideals 
do  not  justify  unauthorized  use  of  computer  resources  nor  do  they  provide  an  adequate 
basis  for  violation  of  any  other  ethical  imperatives  of  this  code. 

1.5  Honor  property  rights  including  copyrights  and  patents. 

Violation  of  copyrights,  patents,  trade  secrets  and  the  terms  of  license  agreements  is 
prohibited  by  law  in  most  circumstances.  Even  when  software  is  not  so  protected,  such 
violations  are  contrary  to  professional  behavior.  Copies  of  software  should  to  made  only 
with  proper  authorization.  Unauthorized  duplication  of  materials  must  not  to  condoned. 

1 .6  Give  proper  credit  for  intellectual  property. 

Computing  professionals  are  obligated  to  protect  the  integrity  of  intellectual  property. 
Specifically,  one  must  not  take  credit  for  other's  ideas  or  work,  even  in  cases  where  the 
work  has  not  been  explicitly  protected  by  copyright,  patent,  etc. 

1 .7  Respect  the  privacy  of  others. 

Computing  and  communication  technology  enables  the  collection  and  exchange  of 
personal  information  on  a  scale  unprecedented  in  the  history  of  civilization.  Thus  there 
is  increased  potential  for  violating  the  privacy  of  individuals  and  groups.  It  is  the 
responsibility  of  professionals  to  maintain  ttie  privacy  and  integrity  of  data  describing 
individuals.  This  includes  taking  precautions  to  ensure  the  accuracy  of  data,  as  well  as 
protecting  it  from  unauthorized  access  or  accidental  disclosure  to  inappropriate 
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individuals.  Furthermore,  procedures  must  be  established  to  allow  individuals  to  review 
their  records  and  correct  inaccuracies. 

This  imperative  implies  that  only  the  necessary  amount  of  personal  information  be 
collected  in  a  system,  that  retention  and  disposal  periods  for  that  information  be  clearly 
defined  and  enforced,  and  that  personal  information  gathered  for  a  specific  purpose  not 
be  used  for  other  purposes  without  consent  of  the  individual(s).  These  principles  apply 
to  electronic  communications,  including  electronic  mail,  and  prohibit  procedures  that 
capture  or  monitor  electronic  user  data,  including  messages,without  the  permission  of 
users  or  bona  fide  authorization  related  to  system  operation  and  maintenance.  User  data 
obsenred  during  the  normal  duties  of  system  operation  and  maintenance  must  be  treated 
with  strictest  confidentiality,  except  in  cases  where  it  is  evidence  for  the  violation  of  law, 
organizational  regulations,  or  this  Code,  in  these  cases,  the  nature  or  contents  of  that 
information  must  be  disclosed  only  to  proper  authorities.  (See  1 .9) 

1 .8  Honor  confidentiality. 

The  principle  of  honesty  extends  to  issues  of  confidentiality  of  information  whenever  one 
has  made  an  explicit  promise  to  honor  confidentiality  or,  implicitly,  when  private 
information  not  directly  related  to  the  performance  of  one's  duties  b^mes  available.  The 
ethical  concern  is  to  respect  all  obligations  of  confidentiality  to  employers,  clients,  and 
users  unless  discharged  from  such  obligations  by  requirements  of  the  law  or  other 
principles  of  this  Code. 

2.  MORE  SPECIFIC  PROFESSIONAL  RESPONSIBILITIES. 

As  an  ACM  computing  professional  I  will . . . 

2.1  Strive  to  achieve  the  highest  quality,  effectiveness  and  dignity  in  both  the 
process  and  products  of  professional  work. 

Excellence  is  perhaps  the  most  important  obligation  of  a  professional.  The  computing 
professional  must  strive  to  achieve  quality  and  to  be  cognizant  of  the  serious  negative 
consequences  that  may  result  from  poor  quality  in  a  system. 

2.2  Acquire  and  maintain  professional  competence. 

Excellence  depends  on  individuals  who  take  responsibility  for  acquiring  and  maintaining 
professional  competence.  A  professional  must  participate  in  setting  standards  for 
appropriate  levels  of  competence,  and  strive  to  achieve  those  standards.  Upgrading 
technical  knowledge  and  competence  can  be  achieved  in  several  waysidoing  independent 
study;  attending  seminars,  conferences,  or  courses;  and  being  involved  in  professional 
organizations. 

2.3  Know  and  respect  existing  laws  pertaining  to  professional  work. 

ACM  members  must  obey  existing  local,  state,province,  national,  and  international  laws 
unless  there  is  a  compelling  ethical  basis  not  to  do  so.  Policies  and  procedures  of  the 
organizations  in  which  one  participates  must  also  be  obeyed.But  compliance  must  be 
balanced  with  the  recognition  that  sometimes  existing  laws  and  rules  may  be  immoral  or 
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Inappropriate  and, therefore,  must  be  chaNenoed.  Vioiation  of  a  law  or  regulation  may  be 
ethical  when  that  law  or  rule  has  Inadequate  moral  basis  or  when  it  oonflicis  ¥rith  arnither 
law  judged  to  be  more  important,  if  one  decides  to  violale  a  law  or  rule  because  it  is 
viewed  as  unethical,  or  for  any  other  reason,  one  must  fuMy  accept  responsibility  for  one's 
actions  and  for  the  consequences. 

2.4  Accept  and  provide  appropriate  professiorMil  review. 

Quality  professionai  work,  espedaliy  in  the  computing  profession,  depends  on 
profes^nal  reviewing  and  critiquing.  Whenever  appropriate,individuai  members  should 
seek  and  utilize  peer  review  as  well  as  provide  critical  review  of  the  work  of  others. 

2.5  Give  comprehensive  and  thorough  evaluations  of  computer  systems  and  their 
impacts,  including  analysis  of  possible  risks. 

Computer  professionais  must  strive  to  be  perceptive,  thorough,  and  objective  when 
evaluating,  recommending,  and  presenting  system  descriptions  and  alternatives. 
Computer  professionals  are  in  a  position  of  special  trust,  and  therefore  have  a  special 
responsibility  to  provide  objective,  credible  evaluations  to  employers,  clients,  users,  and 
the  public.  When  providing  evaluations  the  professional  must  also  identify  any  relevant 
conflicts  of  interest,  as  stated  in  imperative  1.3. 

As  noted  in  the  discussion  of  principle  1.2  on  avoiding  harm,  any  signs  of  danger  from 
systems  must  be  reported  to  those  who  have  opportunity  and/or  responsibility  to  resolve 
them.  See  the  guidelines  for  imperative  1.2  for  more  (Mils  concerning  harm,inciuding 
the  reporting  of  professional  violations. 

2.6  Honor  contracts,  agreements,  and  assigned  responsibilities. 

Honoring  one's  commitments  is  a  matter  of  integrity  and  honesty.For  the  computer 
professionai  this  includes  ensuring  that  system  elements  perform  as  intended.  Also,  when 
one  contracts  for  work  with  another  party,  one  has  an  obligation  to  keep  that  party 
properly  informed  about  progress  toward  completing  that  work. 

A  computing  professionai  has  a  responsibility  to  request  a  change  in  any  assignment 
that  he  or  she  feels  cannot  be  oompleM  as  defined.  Only  after  serious  consideration  and 
with  full  disclosure  of  risks  and  concerns  to  the  employer  or  client,  should  one  accept  the 
assignment.  The  major  underlying  principle  here  is  the  obligation  to  accept  personal 
accountability  for  professional  work.  On  some  occasions  other  ethical  prindpiM  may  take 
greater  priority. 

A  judgment  that  a  specific  assignment  should  not  be  performed  may  not  be  accepted. 
Havirig  clearly  identified  one's  concerns  and  reasons  for  that  judgment,  but  failing  to 
procure  a  change  in  that  assignment,  one  may  yet  be  obligated,  by  contract  or  by  law, 
to  proceed  as  directed.  The  computing  professionars  ethical  judgment  should  be  the  final 
guide  in  deciding  whether  or  not  to  proc^.  Regardless  of  the  decision,  one  must  accept 
the  responsibility  for  the  consequences. 

However,  periorming  assignments  "against  one's  own  judgmenf  does  not  relieve  the 
professional  of  responsibility  for  any  negativo  consequences. 
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2.7  Improve  public  understanding  of  computing  and  its  consequences. 

Computing  professionals  have  a  responsibility  to  share  technical  Knowledge  with  the 
public  by  encouraging  understanding  of  coming,  including  the  impacts  of  computer 
systems  and  their  limitations.  This  imperative  implies  an  obligation  to  counter  any  false 
views  related  to  computing. 

2.8  Access  computing  and  communication  resources  only  when  authorized  to  do  so. 

Theft  or  destruction  of  tangible  and  electronic  property  is  prohibited  by  imperative  1 .2  - 
"Avoid  harm  to  others."  Trespassing  and  unauthorized  use  of  a  computer  or 
communication  system  is  addressed  by  this  imperative.  Trespassing  includes  accessing 
communication  networks  and  computer  systems,  or  accounts  and/or  files  associated  with 
those  systems,  without  explicit  authorization  to  do  so.  Individuals  and  organizations  have 
the  right  to  restrict  access  to  their  systems  so  long  as  they  do  not  violate  the 
discrimination  principle  (see  1.4).  No  one  should  enter  or  use  another's  computer  system, 
software,  or  data  files  without  permission.  One  must  always  have  appropriate  approval 
before  using  system  resources,  including  communication  ports,  file  space,  other  system 
peripherals,  and  computer  time. 

3.  ORGANIZATIONAL  LEADERSHIP  IMPERATIVES. 

As  an  ACM  member  and  an  organizational  leader,  I  will . 

BACKGROUND  NOTE:This  section  draws  extensively  from  the  draft  IFIP  Code  of 
Ethics,especiaily  its  sections  on  organizational  ethics  and  international  concerns.  The 
ethical  obligations  of  organizations  tend  to  be  neglected  in  most  codes  of  professional 
conduct,  perhaps  because  these  codes  are  vwitten  from  the  perspective  of  the  individual 
member.  This  dilemma  is  addressed  by  stating  these  imperatives  from  the  perspective 
of  the  organizational  leader.  In  this  context"ieader"  is  viewed  as  any  organizational 
member  who  has  leadership  or  educational  responsibilities.  These  imperatives  generally 
may  apply  to  organizations  as  well  as  their  leaders.  In  this  context"organizations"  are 
corporations,  government  agencies.and  otiier  "employers,"  as  well  as  volunteer 
professional  organizations. 

3.1  Articulate  social  responsibilities  of  members  of  an  organizational  unit  and 
encourage  full  acceptance  of  those  responsibilities. 

Because  organizations  of  all  kinds  have  impacts  on  the  public,  they  must  accept 
responsibilities  to  society.  Organizational  procedures  and  attitudes  oriented  toward  quality 
and  the  welfare  of  society  will  reduce  harm  to  members  of  the  public,  thereby  serving 
public  interest  and  fulfilling  social  responsibility.  Therefore.organizational  leaders  must 
encourage  full  participation  in  meeting  social  responsibilities  as  well  as  quality 
performance. 

3.2  Manage  personnel  and  resources  to  design  and  build  information  systems  that 
enhance  the  quality  of  working  life. 

Organizational  leaders  are  responsible  for  ensuring  that  computer  systems  enhance,  not 
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degrade,  the  quality  of  working  life.  When  implementing  a  computer  system, 
organizations  must  consider  the  personal  and  professional  development,  ^ysical  safety, 
and  human  dignity  of  all  workers,  ^propriate  human>computer  ergonomic  standards 
should  be  considered  in  system  design  and  in  the  workplace. 

3.3  Acknowledge  and  support  prqser  and  authorized  uses  of  an  organization's 
computing  and  communication  resources. 

Because  computer  systems  can  become  tools  to  harm  as  well  as  to  benefit  an 
organization,  the  leadership  has  the  responsibility  to  clearly  define  appropriate  and 
inappropriate  uses  of  organizational  computing  resources.  While  the  number  and  scope 
of  such  rules  should  be  minimal,  they  should  be  fully  enforced  when  established. 

3.4  Ensure  that  users  and  those  who  will  be  affected  by  a  system  have  their  needs 
clearly  articulated  during  the  assessment  and  design  of  requirements;  later  the  system 
must  be  validated  to  meet  requirements. 

Current  system  users,  potential  users  and  other  persons  whose  lives  may  be  affected  by 
a  system  must  have  their  needs  assessed  and  incorporated  in  the  statement  of 
requirements.  System  validation  should  ensure  compliance  with  those  requirements. 

3.5  Articulate  and  support  policies  that  protect  the  dignity  of  users  and  others  effected  by 
a  computing  system. 

Designing  or  implementing  systems  that  deliberately  or  inadvertently  demean  individuals 
or  groups  is  ethically  unacceptable.  Computer  professionals  who  are  in  decision  making 
positions  should  verify  that  systems  are  designed  and  implemented  to  protect  personal 
privacy  and  enhance  personal  dignity. 

3.6  Create  opportunities  for  members  of  the  organization  to  learn  the  principles 
and  limitations  of  computer  systems. 

This  complements  the  imperative  on  public  understanding  (2.7).  Educational  opportunities 
are  essential  to  facilitate  optimal  participation  of  all  organizational  members.  Op^rtunities 
must  be  available  to  all  members  to  help  tiiem  improve  their  knowledge  and  skills  in 
computing,  including  courses  that  familiarize  them  with  the  consequences  and  limitations 
of  particular  types  of  systems.  In  particular,  professionals  must  be  made  aware  of  the 
da^rs  of  building  systems  around  oversim^ified  models,  the  improbability  of  anticipating 
and  designing  for  every  possible  operating  condition,  and  other  issues  related  to  the 
complexity  of  this  profession. 

4.  COMPLIANCE  WITH  THE  CODE.  As  an  ACM  member  I  will ... 

4.1  Uphold  and  promote  the  principles  of  this  Code. 

The  future  of  the  computing  profession  depends  on  both  technical  and  ethical  excellence. 
Not  only  is  it  important  for  ACM  computing  professionals  to  adhere  to  the  principles 
express^  in  this  Code,  each  member  should  encourage  and  support  adherence  by  other 
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members. 


4.2  Treat  violations  of  this  code  as  inconsistent  with  membership  in  the  ACM. 

Adherence  of  professionals  to  a  code  of  ethics  is  largely  a  voluntary  matter.  However, 
if  a  member  does  not  follow  this  code  by  engaging  in  gross  misconduct,  membership  in 
ACM  may  be  terminated. 


This  Code  and  the  supplemental  Guidelines  were  developed  by  the  Task  Force  for  the 
Revision  of  the  ACM  Code  of  Ethics  and  Professional  Conduct:  Ronald  E.  Anderson, 
Chair,  Gerald  Engel,  Donald  Gotterbam,  Grace  C.  Hertiein,  Alex  Hoffman,  Bruce  Jawer, 
Deborah  G.  Johnson,  Doris  K.  Lidtke,  Joyce  Currie  Little,  Dianne  Martin,  Donn  B.  Parker, 
Judith  A.  Perrolle,  and  Richard  S.  Rosenberg.  The  Task  Force  was  organized  by 
ACM/SIGCAS  and  funding  was  provided  by  the  ACM  SIG  Discretionary  Fund.  This  Code 
and  the  supplemental  Guidelines  were  adopted  by  the  ACM  Council  on  October  16, 1992. 
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The  Four  Step  Anelyeie  Proceee  * 

Slepl.  Anelyie  the  eituetlon.  What  ie  the  eu^ect  of  the  ceee;  whet  le  tt  ell  ebout? 

A.  What  are  the  relevant  facts? 

B.  Who  are  the  stakeholders,  that  is,  who  has  an  interest,  or  stake,  in  the  outcome? 

Step  II.  Make  a  defensible  ethical  decision?  (Refer  to  Chapter  1  for  details.) 

A.  Isolate  the  ethical  issues. 

1 .  Should  someone  have  done  or  not  done  something? 

2.  Does  it  matter  that ...?  (reasons  and  excuses) 

B.  Examine  the  legal  issues. 

C.  Consult  guidelines. 

1 .  Do  corporate  policies  apply? 

2.  What  codes  of  conduct  apply? 

3.  Does  the  action  violate  the  Golden  Rule? 

4.  Who  benefits?  Who  is  harmed? 

5.  Does  the  action  pass  tests  for  right  and  wrong? 

D  Discover  the  applicable  ethical  prindples. 

1 .  Explore  ways  to  minimize  harm. 

2.  Analyze  pertinent  rights  and  duties. 

3.  Define  professional  responsibilities. 

4.  Examine  the  situation  in  terms  of  egoism  and  utilitarianism. 

5.  Apply  concepts  of  consistency  and  respect. 

E.  Make  a  defensible  choice. 

STEP  III.  Describe  steps  to  resolve  the  current  situation. 

A.  What  are  the  options  at  this  time? 

B.  Which  option(s)  do  you  recommend? 

C.  Defend  the  legality  and  ethicality  of  your  recommendation. 

D.  How  would  you  implement  your  recommendation? 

E.  Recommend  short-term  corrective  measures. 

1 .  Analyze  the  pivot  points. 

2.  Alter  the  parameters. 

STEP  IV.  Prepare  policies  and  strategies  to  prevent  recurrence. 

A.  What  organizational,  political,  legal,  technological,  societal  changes  are  needed? 

B.  What  are  the  consequences  of  your  suggested  changes? 

1 .  What  happens  when  this  resolution  is  invoked? 

2.  What  obstacles  might  prevent  your  plan  from  working? 

3.  Why  should  the  organization  implement  the  changes? 

4.  How  do  the  changes  benefit  the  organization?  Are  they  marketable,  or  do 
they  further  public  relations?  (Perhaps  perform  a  cost/benefit  analysis.) 

5.  Do  the  changes  increase  the  net  good  for  those  concerned?  Does  anyone 
get  hurt? 

6.  Do  the  changes  reflect  human  rights  and  reflect  common  duties? 

*  Source:  Ethical  Decision  Making  and  Information  Technology  by  Kallman  and  Grillo 
(Mitchell  McGraw-Hill,  1993) 
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CASE  WORKSHEET  (see  Chapter  3  for  datella  on  how  to  carry  out  each  atop)  * 

I.  Find  the  facts 

A.  List  the  relevant  facts: _ 


B.  List  the  stakeholdersi 


II.  Make  a  defensible  ethical  decision. 

A.  Isolate  ethical  issues  (Should  someone  have/have  not  done  something?) 


B.  Examine  the  legal  issues: _ 

C.  Consult  guidelines 

Corporate  policies,  codes  of  Conduct: 


Golden  Rule 


Who  benefits?  Who  is  harmed?. 


Tests  for  right  and  wrong: 
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D.  Discover  the  applicaUe  ethical  prindpies 


Least  harm 


Rights  arxi  duties 


Professional  responsibilitiea 


Self  interest  and  utilitarianism 


Consistency  and  respect 


E.  Make  a  defensible  choice 


III.  Describe  steps  to  resolve  the  current  slhjation. 

A.  Options _ 


B.  Recommendation 


C.  Defense 


D.  Implementation 


E.  Short-term  corrective  measures 


IV.  Prepare  policies  and  strategies  to  prevent  recurrence 

A.  Describe  the  organizational,  political,  legal,  technological,  or  societal  changes 
needed; _ 


B.  Describe  the  consequences  of  your  suggested  changes: 
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Real-World  Software  Engineering 

IV  PROJECTS 

This  section  is  divided  into  five  parts.  Part  a  provide  an  overview  of  the  three  types 
of  projects  (small,  extended,  maintenance)  around  which  the'course  is  organized.  This 
is  followed  by  a  discussion  about  significant  issues  to  consider  when  selecting  projects 
for  a  project  oriented  class  (p^  b).  Once  a  project  is  chosen  it  must  be  car^ully 
managed  and  evaluated.  Project  management  tediniques  and  tools  are  presented 
in  part  c.  Sample  projects  are  included  In  part  d.  Part  e  consists  of  an  extended 
discussion  of  our  approach  to  the  management  of  a  large  project. 


a.  Introduction  to  Projects. 

The  course  is  organized  around  three  types  of  project.  A  brief  description  of  each  of 
the  three  projects  follows. 


1.  Small  project  •  The  requirements  are  provided  to  the  students  who  are 
expected  to  specify,  design,  code,  and  test  a  solution.  The  small  project  is 
scheduled  for  weelU  2  through  6  of  the  first  semester.  Since  work  must  begin 
quickly,  controlling  disciplines  are  imposed  upon  the  teams  with  minimum 
justification  at  this  point.  For  example,  students  are  immediately  introduced 
to  estimation,  scheduling,  project  organization,  configuration  management, 
quality  assurance,  and  verification  and  validation  techniques  by  "living  them" 
but  only  later  are  these  topics  formally  addressed  in  lectures.  While  the 
project  is  implemented  in  a  language  with  which  the  students  are  already 
proficient,  Ada  specifications  are  used  in  high-level  design. 

2.  Extended  project  -  Beginning  with  an  inKial  request  from  a  "real  customer", 
students  are  expected  to  complete  all  aspects  of  a  solution,  from  requirements 
engineering  (elicitation,  analysis,  and  specification)  through  implementation. 
This  project  t^ins  in  week  5  of  the  first  semester  arid  continues  through  week 
1 1  of  the  second  semester.  Analysis  and  design,  through  Ada  spedfications, 
are  to  be  completed  by  the  end  of  the  first  semester  with  detailed  design, 
coding,  and  testing  to  follow  in  ttie  second  semester.  Ada  is  used  as  the 
notation  for  requirements  specification  and  design.  Structured  analysis  and 
design  techniques  are  applied  to  this  project.  DOD-STD-2167a  [2167A]  is 
used  as  the  standard  for  the  required  documents  and  procedures,  internal 
project  reviews  are  emphasized  [Bruegge  91]. 


3.  Maintenance  p 


Students  perform  major  maintenance  (including 
corrective,  enhancement,  and  ada^ive  activities)  on  an  existing  software 
system.  A  complete  and  sound  set  of  system  documents,  which  adhere  to 
accepted  software  engineering  standards,  is  provided.  The  maintenance 


project  is  scheduled  for  weeks  6  through  1 1  of  the  second  semester.  The 
project  chosen  is  one  that  has  been  previously  implemented  in  Ada  with 
object-oriented  techniques.  A  variety  of  maintenance  tasks,  including  those 
described  by  Engle.  Ford,  and  Korson  [Engle  89],  are  assigned.  The  students 
are  required  to  perform  multiple  concurrent  maintenance  tasks  on  this  large 
Ada  artifact  [Callis  91].  These  maintenance  activities  require  the  use  of 
disciplined  change  control  and  the  ability  to  work  with  a  large  unfamiliar 
artifact. 


We  specifically  recommend  that  students  work  in  project  teams,  assigned  to 
developing  a  software  product  for  a  customer.  The  customer  may  be  a  real  customer 
who  has  a  genuine  software  need,  or  the  customer  may  be  role-played  by  the 
instructor  or  a  colleague  with  a  simulated  software  need.  In  either  case,  the  customer 
makes  a  request  to  initiate  the  project.  The  request  may  be  given  orally  or  in  writing 
and  consists  of  a  brief  statement  intended  to  convey,  in  the  customer’s  language,  the 
essence  of  the  desired  product.  At  this  point  the  students  are  charged  with  developing 
a  problem  definition.  It  is  emphasized  that  defining  the  problem  requires  a  real 
understanding  of  the  problem  domain.  The  specific  form  of  the  problem  definition  to 
be  developed  will  vary  depending  on  the  particular  course  and  instructor  preference 
but  should  be  clearly  stated  and  demonstrated  by  the  instructor.  Students  should  also 
be  provided  with  techniques  for  eliciting  requirements  as  well  as  for  working  in  groups. 
Techniques  include  interviewing,  observation,  context-free  questions,  brainstorming, 
scenarios,  reviews,  and  effective  meetings  (Gause  &  Weinberg,  1989,  Pressman, 
1988,  Weinberg,  1982,  Metzger,  1987). 


b.  Selecting  a  project 

The  success  of  our  approach  is  dependent  on  the  selection  of  appropriate  software 
projects.  The  selected  software  project  must  accomplish  something  more  than  a  mere 
calculation  and  represent  a  real  world  problem  of  sufficient  complexity  so  that  the 
requirements  gathering  challenges  the  students.  Other  factors  in  project  selection 
include  required  domain  knowledge,  non-functional  requirements,  and  incremental 
development. 

In  the  real  world,  the  customer  has  significantly  more  domain  knowledge  than  the 
software  developer,  who  must  acquire  some  of  that  knowledge  to  successfully  develop 
the  system.  There  is  rarely  sufficient  time  within  the  duration  of  a  class  to  gain  this 
knowledge.  Consequently,  both  the  instructor  and  the  students  must  already  be 
familiar  with  the  knowledge  domain  of  the  selected  project.  Undertaking  a  project 
which  requires  exotic  domain  knowledge  by  the  instructor  or  the  students  merely  adds 
distracting  complications  to  the  project  as  either  struggles  to  understand  the  domain. 
While  the  choice  of  an  exotic  application  might  excite  the  students,  the  instructor  may 
be  unable  to  comfortably  portray  a  knowledgeable  customer.  Even  with  familiar  tasks, 
students  still  have  difficulty  capturing  the  customer’s  needs  and  designing  a  solution. 


This  experience  helps  them  understand  the  essential  difficulty  of  requirements 
gathering.  Familiarity  with  the  project  domain  also  reduces  the  need  for  the  instructor 
to  correct  unnecessarily  complicated  design  assumptions. 

Most  students  are  familiar  with  common  mechanical  devices.  Computerizing  simple 
mechanical  devices  is  a  useful  source  of  project  ideas.  From  one  model  of  a  device, 
many  projects  can  be  developed.  For  example,  students  understand  the  model  of  a 
machine  which  accepts  money  and  dispenses  products.  Variations  on  this  model 
which  we  have  used  on  recent  projects  include  the  computerization  of  a  snack  vending 
machine  and  a  videotape  vending  machine.  The  model  can  also  be  reversed  to  that 
of  a  machine  which  accepts  products  and  dispenses  money.  A  variation  on  this  is  a 
recycling  machine  which  accepts  empty  cans  and  bottles  and  dispenses  money  in 
exchange  for  these  items.  The  similarity  of  these  variations  is  useful  if  multiple  student 
projects  need  to  be  developed  concurrently.  Even  though  students  notice  this 
similarity,  they  quickly  learn  that  each  project  is  very  different  because  of  the 
customer’s  needs.  For  example,  the  snack  vending  machine  is  continually  replenished 
by  the  owner  while  the  videotape  vending  machine  is  restocked  by  a  user  returning  a 
videotape. 

Another  factor  in  project  selection  is  the  presence  of  non-functional  requirements. 
Non-functional  requirements  are  requirements  that  do  not  relate  directly  to  the 
functions  or  operations  to  be  performed  by  the  system.  Students  must  learn  to 
recognize  non-functional  requirements  such  as  the  need  for  rapid  responses  to 
customer  requests  and  appropriate  user  interfaces.  Again,  familiarity  with  the  selected 
model  helps  the  students  to  easily  identify  the  non-functional  requirements. 

The  ability  to  provide  incremental  development  is  another  factor  in  project  selection. 
For  student  satisfaction  with  the  learning  experience,  it  is  important  for  them  to  deiiver 
a  functioning  system.  If  a  project  has  several  distinct  functional  components,  it  is  more 
likely  that  at  least  some  of  those  components  can  be  delivered.  For  example,  a  video¬ 
tape  vending  machine  keeps  track  of  its  tapes,  records  charges  to  user’s  charge  cards, 
accepts  money,  and  accepts  and  dispenses  tapes.  Each  of  these  functions  can  be 
developed  and  tested  separately,  giving  the  student  some  sense  of  accomplishment. 
Selecting  a  project  conducive  to  incremental  development  models  the  real  world  in  that 
customers  sometimes  have  to  cut  back  on  their  expectations.  Also,  software  reuse 
and  integration  testing  are  more  easily  demonstrated  in  systems  that  can  be 
incrementally  developed. 

In  project  selection,  two  strong  motivating  factors  for  students  have  been  their 
familiarity  with  the  problem  domain  and  the  possibility  of  others  using  their  software. 
We  have  found  that  school-related  projects  are  well  received  by  students.  Automating 
aspects  of  a  departmental  library  or  advisement  system,  tracking  the  distribution  of 
athletic  equipment,  automating  a  dormitory  assignment  lottery,  and  detecting  program 
plagiarism  are  examples  of  such  projects.  An  additional  virtue  of  school-related 
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TEST  PROCEDURE  FORM 
Test:  E  (Total  Percentage) 

Test  Version :  1.0 

Description:  This  test  is  performed  to  ensure  that  the  system 

will  advise  the  user  to  continue  on  with  the  next 
filter  even  if  the  last  filter's  percentage  was 
not  80%  or  greater  if  the  total  percentage  is 
greater  than  80%. 

Requirements:  19 

Prerequisites:  B8 

Test  Data  Required:  TD_102A.TST  and  TD_102B.TST 
Test  Steps: 

1.  Enter  program  names  TD_.TST  and  TD_.TST. 

2.  Run  filter  one  (should  contribute  10%  to  Total). 

3.  Run  filter  two  (should  contribute  15%  tojotal). 

4.  Run  filter  three  (should  contribute  20%  to  Total). 

5.  Piclc  each  procedure  from  first  program  and  run  with  every 
other  procedure  from  second  program  in  filter  four 
(should  contribute  10%  to  Total) . 

6.  Piclc  each  procedure  from  first  program  and  run  with  every 
other  procedure  from  second  program  in  filter  five. 

(should  contribute  10%  to  Total). 

7.  Run  filter  six  (should  contribute  11.85%  to  Total  because 

of  possible  15%  is  11.85%). 

8.  Run  filter  seven  (should  contribute  7.9%). 

9.  Total  shoud  be  (84.75%)  verify  system  advises  you  to  continue 
on  with  filter  eight  even  though  filter  seven's  percentage 
was  only  79%. 


TEST  PROCEDURE  FORM 


Test:  F  (Menu  Key  torture  test) 

Test  Version:  1.0 

Description:  This  test  is  performed  to  check  that  Menus  do  not 

take  incorrect  actions  vdien  meemingless  keys  are 
pressed. 


Requirements :  3 
Prerequisites:  A1 


Test  Data  Required:  TD_1A.TST  emd  TD_1B.TST 


Test  steps: 

1.  Enter  TD_1A.TST  for  first  program. 

2.  Enter  TD_1B.TST  for  second  program. 

3.  When  menu  for  Filter  1  is  displayed  press  the  key  indicated 
in  the  matrix  below  and  record  the  results. 

4.  Exit  system. 


TEST  DATA  MATRIX  (F) 


rrww  Mya 

fpirfd 

MMttlt 

Rctvel 

Reeuli 

KrtdH 

OHMDte 

Rejected 

■1 

<Oown  Arrow> 
<IUtTUIW» 

Rejected 

Cuecoaier  eeye  thie  ie  not  e  preblaa  do  not 
run. 

<P1> 

<RmmN> 

Rejected 

Rejected 

<RmmN> 

Rejected 

CustoMr  eeye  thie  ie  not  e  probleei  do  not 
run. 

<I>  <RtTURN> 

R«iecttd 

<R>  <iumiRN> 

Rejected 

<trACt  ■All> 

■(•jactad 

Bi 

Cuetoeier  eeye  thie  ie  not  e  probleei  do  net 
run. 

<t> 

Rejected 
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Test 

Name 

Description 

A1 

Prompt  for  source  Pgms 

A2 

Exit  test 

A3 

Report  information 

Bla 

Filter  1  Physical  lines 
/  comments 

Bib 

Filter  1  constructs 

Blc 

Filter  1  percentage 

Bid 

Filter  1  torture 

B2a 

Filter  2  Globa  VARa 

B2b 

Filter  2  Global  CONSTs 

B2c 

Filter  2  Global  TYPES 

B2d 

Filter  2  Global 
f unc t ions /procedures 

B2e 

Filter  2  Total  #  of 
Globals 

B2£ 

Filter  2  percentage 

B2g 

Filter  2  torture 

B3a 

Filter  3  function  / 
procedure  interfaces 

B3b 

Filter  3  percentage 

B3c 

Filter  3  torture 

B4a 

Filter  4  physical  lines 
/  comments 

B4b 

Filter  4  constructs 

B4c 

Filter  4  percentage 

B4d 

Filter  4  torture 

Result 
Problem  P=Pass 
Test  Run  Report  F=Fail 
Ver  by  Numbers  N=Not  Run 
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Test 

Name 


Description 


Result 
Problem  P=Pass 
Test  Run  Report  F=Fail 
Ver  by  Numbers  N=Not  Run 


Filter 

5 

Global  VARs 

Filter 

5 

Global  CONSTs 

Filter 

5 

Global  TYPES 

Filter 

5 

function  / 

procedures 

Filter 

5 

total  #  of 

Globals 

Filter 

5 

percentage 

Filter 

5 

torture 

Filter 

6 

keywords 

Filter 

6 

percentage 

Filter 

7 

Identifiers 

Filter 

7 

functions  / 

procedures 

Filter 

7 

percentage 

Filter 

7 

torture 

Filter 

8 

functions 

Filter 

8 

procedures 

Filter 

8 

percentage 

Filter 

8 

torture 

30  seconds /response 

Help  test 

Total  percentage  test 

Menu  Key 

torture  test 

F 


Problon  Report  Form 


PROBLEM  SUBMISSION:  Problem 

Originator :  Report  *. 

Date: 

Version  Number  Tested: 

Problem  Description: 

Was  the  problem  found  by  a  test?  Yes _  No___ 

If  yes,  give  test  name: 

Input : 

Expected  Result :  • 

Actual  Result: 

Additional  Comments: 


PROBLEM  RESOLUTION: 

Name: 

Date: 

Disposition 

Problem  Fixed  _  Not  a  Problem  _  Duplicate  Problem  _ 

If  this  is  a  duplicate  problem  then  give  the  number  of  the 
report  on  which  this  problem  was  previously  identified  _ 


Comments: 


Problon  Report  Tracking  Form 


Disposition: 
Fixed,  Not  a 

Report  Ver  Date  Date  Problem, 

Number  Tested  Reported  Returned  Duplicate 


Closed 


VI  student  assessment 


We  use  tests  and  quizzes  for  two  reasons;  to  encourage  students  to  keep  up  on  their 
reading  assignments  and  to  evaluate  their  understanding  of  fundamental  software 
engineering  concepts.  Students  are  encouraged  to  keep  up  with  the  reading  assignments 
by  the  use  of  frequent  quizzes.  Students  who  have  completed  their  reading  assignments 
before  the  quiz,  will  generally  do  well  on  them.  An  in-dass  review  of  the  quiz  enables  the 
instructor  to  locate  confusions  about  the  reading  material  in  real-time.  The  discovery  of 
confusion  is  not  delayed  until  a  major  test  has  been  given  and  graded.  Concepts  are 
both  learned  and  lived.  The  major  written  examinations  go  over  the  details  of  the 
readings.  By  the  time  a  major  examination  is  given,  students  have  read  the  material,  had 
a  quiz  on  it,  and  started  to  apply  the  principles  in  a  project. 

Below  are  several  sample  quizzes  and  the  answers  we  would  accept.  There  are  also 
some  sample  tests.  We  give  several  types  of  tests.  Some  tests  have  both  a  take  home 
and  an  in-dass  part.  The  take-home  portion  is  used  for  questions  which  require  careful 
application  of  concepts  learned  in  dass  and  questions  on  professional  issues.ake  home 
portion  of  the  exam.  We  also  have  students  review  deliverables  as  take  home  portions 
of  the  exam.  This  motivates  them  to  carefully  synthesize  and  apply  concepts  learned  in 
class.  A  composite  of  their  criticisms  of  the  first  semester  deliverables  is  used  when 
introducing  the  extended  projed  at  the  beginning  of  the  second  semester.  The  in-class 
portion  of  each  test  is  preened  by  a  study  guide.  The  study  guide  is  included  here 
along  with  each  test. 


QUIZZES 


CSCI  3250  QUIZ/EXERCISE  1 


1.  The  qualities  looked  for  in  software  depend  on  one's  point  of  view.  Mynatt 
describes  three  different  categories  of  people  to  whom  good  software  quality  is 
important.  Each  views  a  software  system  l^m  a  different  perspective. 

Name  the  three  categories  of  people  and.  for  each,  list  one  software  quality  that 
is  important  to  them. 


a.  Sponsor  -  Any  of  following  qualities 

Low  costs 

Increased  productivity 
Flexibility 
Efficiefficy 
Reliability 

b.  User  -  Any  of  following  qualities 

Functionality 
Ease  of  learning 
Ease  of  remembering 
Ease  of  use 
Efficiency 
Reliability 

c.  Maintalner/modifier  -  Any  of  following  qualities 

Minimum  errors 
Good  documentation 
Readable  code 
Good  design 
Reliability 
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csa  3250  QUIZ€XERCI8E  2 


ChooM  OM,  but  not  both,  of  ttio  quootlont  bolow  and  anawor  It 


1.  According  to  Mynatt,  the  floats  phase  actually  has  two  components.  Name  and 
briefly  describe  these  two  parts  of  the  analysis  phase. 

(1)  Requirements  analyia  involves  defining  the  problem 
end  the  requirements  thst  must  be  met. 

(2)  Specification  describes  the  technical  requirements 
for  the  system;  e.g.  specifying  what  the  system  is  to 
do  and  any  operational  constraints.  Specification  is 
a  refinement  of  requirements  analysis  and  involves 
the  creation  of  testable  requirements. 


2.  Structured  analysis  is  a  widely  used  approach  to  analysis.  Name  and  briefly 
describe  the  components,  according  to  K^att,  of  a  structured  analysis  model. 

Context  diagram 
Data  flow  diagrams 
Data  dictionary 
Activity  specifications 
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QUIZ/EXERaSE  3 


CSC!  3250 


Answw  only  on#  of  tho  throo  quootions  that  follow. 


1 .  There  are  two  software  design  strategies  that  have  been  widely  adopted.  Name 
and  briefly  describe  each. 


2.  According  to  Sommerville.  "the  most  important  design  quality  attribute  is 
maintainability."  Coupling  and  cohesion  affect  the  maintainability  of  a  system. 
Briefly  define  and  distinguish  between  coupling  and  cohesion. 


3.  Are  structure  charts  analysis  or  design  documents?  What  does  a  structure  chart 
show? 


csa  3250  QUIZ/EXERaSE  4 


Answer  only  one  of  tho  two  quostlons  that  foNow. 


1 .  (a)  What  is  black-box  testing?  (b)  What  is  white-box  testing?  (c)  For  black-box 

testing,  from  what  are  the  tests  derived  (i.e.  what  must  you  have  knowtodge  of  in 
order  to  construct  black-box  tests)?  (d)  Repeat  part  (c)  for  white-box  testing. 

(a)  Black-box  tatting,  or  functional  taating,  taata  the  ayatam  from  an 
external  standpoint;  i.a.  tho  ayatam  la  vlawad  aa  a  black-box  whoaa 
behavior  la  examined  aolely  from  Ha  inputa  and  ralatad  outputa.. 

(b)  White-box  taating,  or  atructurai  taating,  conaMara  the  intamala  of  the 
ayatam;  i.a.  the  intamal  atructura  (the  coda)  la  axamlnad  to  conaidar 
wrhat  taata  to  run.  Taata  are  conatruclad  ao  aa  to  "cover”  (to  axerclaa) 
all  of  the  coda. 

(c)  Black-box  taata  are  derived  from  the  ayatam'a  apacHIcationa. 

(d)  White-box  taata  are  derived  from  the  Intamal  program  atructura;  i.a. 
the  coda. 


2.  Name  and  describe  the  three  categories  of  software  maintenance,  (b)  Which 
type  is  the  most  prevalent  (i.e.,  in  practice,  which  category  comprises  the  highest 
percentage  of  software  maintenance  efforts)? 

(a)  Corractiva  -  maintananca  to  corract  dafacta 

Parfactiva  (or  anhancamant)  -  maintananca  to  add  naw  faaturaa  and 
functionality;  l.a.  dua  to  a  changa  in  raquiramanta 

Adaptiva  -  maintananca  dua  to  a  changa  In  tha  oparatlonal 
arvironmant 

(b)  Parfactiva  is  tha  moat  pravalant;  approximataly  55%  of  all  maintananca 
is  parfactiva. 
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csa  3250  QUIZ/EXERCISE  5 


1. 


Distinguish  between . 
an  example  of  each. 


8  documentatioo  and  pretiuct  docui 


and  give 


Process  documentation  deals  srlth  the  software 
development  process.  Process  documentation  Includes 
such  things  as  project  management  plans,  schedules, 
development  standards,  and  meeting  notes/reports.  Its 
primary  purpose  Is  to  assist  In  the  management  of 
software  development. 

Product  documentation  deals  with  the  software  product 
that  Is  being  developed.  It  Includes  such  things  as  users 
manuals.  Installation  guides,  requirements  documents, 
design  documents,  source  code,  and  test  plans. 
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csa  3250  QUIZ/EXERCISE  6 


NAME:  Antwtr  K«y 


(a) 

(b) 


Distinguish  between  funcMonal  reouirements  and  non-functional  requirements. 
For  your  team's  project,  give  a  specific  example  of  a  functional  requirement  and 
of  a  non-functional  requirement. 


(a)  Functional  reouirements  are  requirements  that  relate  directly  to  the  system's 
functionality;  i.e.,  they  describe  how  the  system  should  behave. 

Non-functional  reouirements  do  not  relate  to  functions  of  the  system.  They  are 
requirements  or  constraints  (restrictions)  under  which  the  system  must  operater 
and  standards  that  must  be  met. 

(b)  See  Mynatt,  pages  70-74,  and  Sommerville,  pages  92-95,  for  ideas. 


csa  3250  QUIZ/EXERaSE  7 


NAME: 


Answmr  onivon*  of  tho  two  quostiont  that  follow. 

1 .  (a)  Aooording  to  Sornmervilie.  tfw  raliabiiity  of  a  software  system  is  a  measure 

of: 

how  well  tho  software  ofovldea  the  eervlcoa  expected  of  It 

bv  Its  users. _ 

(b)  Sornmervilie  discusses  four  different  metrics  which  have  been  used  to 
assess  software  reliability.  Name  two  of  these  reliability  metrics. 

Any  two  of  the  foliowring: 

(1 )  Probability  of  failure  on  demand  (3)  Mean  time  to  failure 

(2)  Rate  of  failure  occurrence  (4)  Availability 


2.  Mynatt  describes  five  general  factors  that  are  related  to  user  interface  quality. 
Identify  four  of  them. 

Any  four  of  the  following: 


(1)  Ease  of  learning 

(4)  Ueer  satisfaction 

(2)  Speed  of  uee 

(5)  Knowledge  retention 

(3)  Frequency  of  user  errore 
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csa  3250  QUIZ/EXERCISE  8 


NAME:  CofiUMMlts  of  otudont  loooonooo 


All  Miloijs  rotponoM  will  bo  conoldotod  corroetl 


There  has  been  a  lot  of  discussion  about  ethics  and  computing.  List  what  you  think  are 
three  ethicai  issues  in  computing. 

*  Security  of  data  being  transmitted  electronically  (encryption/decryption) 

*  Software  ownership;  licensing;  piracy;  plagiarism;  pricing 

*  Accessing  information  without  authorization 

*  Computer  crime 

*  Software  quaiity: 

•  released  without  adequate  testing  or  with  known  deficiencies 

•  providing  quaiity  product  at  reasonable  cost 
-  safety  criticai  systems 

*  Support  policies  (on  outside  of  package) 

*  Viruses 

*  Privacy:  -  on  systems  such  as  CompuServe 

*  Issue  of  employee  developing  software  for  one  empioyer  and  not  be  allowed  to 
take  it  to  anouther  employer 

*  Al  -  trying  to  duplicate  human  brain,  human  thoughts 

*  Monitoring;  -  e-mail 

*  Abuse  of  resources  on  Internet 

*  Copying  processor  architecture 
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NAME:  An&umKaff 


1.  Completo  the  folloitving  sentence  in  5  words  or  1088: 

Configuration  management  is  concerned  with  chanae  control 


2.  What  does  it  mean  when  something  is  tfiSfiliDfid? 

K  la  placed  under  configuration  management  control  (U.  It  becomes  a 
configuration  Hem)  and  thereafter  changes  can  only  be  made  by  going 
through  the  establlahed  change  control  proceea. 


3.  One  of  the  most  important  roies  of  quaiity  assurance  (QA)  is  the  deveiopment  of 
product  stendards  and  process  standards. 


(a)  Give  a  specific  exampie  of  a  process  standard. _ 

Any  of  the  following:  Design  review  conduct 

Submieelon  of  documents  to  CM 
Version  releaee  process 
Projact  plan  approval  process 
Change  control  process 
Teat  recording  process 

(b)  Give  a  specific  exampie  of  a  product  standard.  _ 

Any  of  the  following:  Design  review  form 

Document  naming  standard 
Procsdure  hsadsr  format 
Programming  standards 
Pro)^  plan  format 
Change  request  form 
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TEST  1  8TU0Y  QINOE 


Note:  1.  Test  1  covers  lectures  and  reading  through  week  7  of  the  syllabus. 

2.  Understand  the  concepts  god  be  able  to  apply  them. 

3.  If  a  topic  is  not  on  review  sheet.  It  is  not  on  the  test. 


1.  Name  the  phases  of  the  software  life  cycle.  For  each,  describe  the  purpose, 
activities  carried  out  in  the  phase,  inputs,  outputs,  and  documents  p^uced. 

2.  Understand  the  components  of  the  structured  analysis  and  design  models  being 
used  in  your  team  project,  including  the  notation  used.  This  includes: 

a)  statement  of  scope  (narrative  overview);  b)  context  diagram; 

c)  data  flow  diagrams  (leveling,  bfldandng);  d)  data  dictionary; 

e)  structure  chart;  f)  module  descriptions 

3.  Sommervilie  says  that  a  major  difficuity  is  establishing  large  software  system 
requirements  is  that  the  problems  are  usually  "wicked  problems."  What  is  a 
wicked  problem  and  what  is  the  major  difficulty?  Give  some  examples? 

4.  Distinguish  between  a  requirements  definition  and  a  requirements  specification? 
Why  is  it  useful  to  draw  a  distinction,  as  Sommervilie  does,  between  a 
requirements  definition  and  a  requirements  specification? 

5.  a)  Distinguish  between  functional  requirements  and  non-functional 

requirements?  Give  examples. 

b)  Describe  the  three  principal  classes  of  non-functional  requirements. 

6.  Consider  Exercises  5.2  and  5.8  (ps^  100)  of  Sommervilie. 

7.  Regarding  software  reviews,  or  walkthroughs: 

a)  What  is  the  purpose? 

b)  Who  participates  and  what  are  the  different  roles? 

c)  What  are  some  standard  guidelines  for  effective  reviews? 

8.  Define  and  distinguish  between  coupling  and  cohesion?  Explain  why  maximizing 
cohesion  and  minimizing  coupling  leads  to  more  maintainable  systems. 

9.  in  evaluating  a  design,  two  major  issues  need  to  be  considered.  First,  does  the 
design  fulfill  the  requirements;  second,  does  it  meet  established  design 


TmI  1  study  QuMe  •  Pagu  12 


standards?  What  types  of  standards  ara  being  referred  to? 

10.  What  are  the  three  key  design  goals? 

11.  Describe  these  process  models  and  give  the  strengths  and  weaknesses  of  each, 

a)  waterfall  model;  b)  prototyping:  c)  spiral  model. 

d)  Consider  Exercise  6.7,  page  1 19.  of  Sommenrille. 

12.  Qualities  looked  for  in  software  depend  on  one’s  point  of  view.  Mynatt  describes 
three  categories  of  people  to  whom  good  software  quality  is  important.  Each 
views  a  software  system  from  a  different  perspective.  Name  the  three  categories 
of  people  and.  for  each,  list  the  software  qualities  that  are  important  to  them. 

13.  According  to  Sommerville.  what  are  the  key  attributes  of  a  well-engineered 
software  system,  assuming  it  provides  tfie  required  functionality? 

14.  According  to  Mynatt.  the  aoabffiia  phase  actually  has  two  components.  Name 
and  briefly  describe  these  two  parts  of  the  analysis  phase. 

15.  Name  and  describe  the  two  widely  adopted  software  design  strategies. 


16.  a)  What  is  black-box  testing?  Describe  some  black-box  testing  techniques. 

b)  What  is  white-box  testing?  Describe  some  white-box  testing  techniques. 

c)  For  black-box  testing,  from  what  are  the  tests  derived  (i.e.  what  must  you 
have  knowledge  of  in  order  to  construct  black-box  tests)? 

d)  For  white-box  testing,  from  what  are  the  tests  derived  (i.e.  what  must  you 
have  knowledge  of  in  order  to  construct  white-box  tests)? 

17.  Name.describe.  and  give  specific  examples  of  the  three  types  of  software 
maintenance.  Which  is  the  most  pre^lent?  Which  would  you  ejqpect  to  be  most 
prevalent  in  the  first  six  months  after  a  new  product  is  released.  Why? 


1 8.  Distinguish  between  process  documentation  and  product  documentation  and  give 
examples  of  each.  For  each  type,  for  whom  is  it  intended,  what  is  the  purpose, 
and  how  long  will  the  documentation  likely  be  used? 


19.  Discuss  factors  which  affect  group  communication.  Give  suggestions  that  an 
organization  could  consider  in  improving  group  effectiveness. 

20.  What  is  meant  by  traceabilitv  of  requirements  throughout  the  software 
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development  process.  Describe  specifically  how  this  could  be  provided  in 
design?  in  testing? 


13 


TmI  1  study  Quldt  •  Pag*  14 


csa  3250  TEST  1, 


NAME;  Anawfar  Kay 


1 .  (32  points)  Write  the  letter  of  the  correct  answer  in  the  space  provided  to  the  left  of 
each  question. 

A.  The  phase  in  which  the  software  architecture  is  established  is 

(a)  requirements  analysis  &  specification  (d)  maintenance 

(b)  design  (e)  all  of  these 

(c)  implementation 

AIB.  B.  The  phase  in  which  test  plans  and  test  cases  are  developed  is 

(a)  requirements  analysis  &  spedfication  (d)  maintenance 

(b)  design  (e)  all  of  these 

(c)  implementation 

_E_  C.  The  phase  in  which  documentation  is  produced  is 

(a)  requirements  analysis  &  specification  (d)  maintenance 

(b)  design  (e)  all  of  these 

(c)  implementation 

JL  D.  The  phase  in  which  the  client's  problem  is  defined  and  recorded  is 

(a)  requirements  analysis  &  specification  (d)  maintenance 

(b)  design  (e)  all  of  these 

(c)  implementation 

_Q_  E.  The  phase  in  which  the  structure  chart  is  developed  is 

(a)  requirements  analysis  &  specification  (d)  maintenance 

(b)  design  (e)  ail  of  these 

(c)  implementation 

*  ^  F.  The  phase  in  which  the  leveled  set  of  data  flow  diagrams  is  developed  is 

(a)  requirements  analysis  &  specification  (d)  maintenance 

(b)  design  (e)  all  of  these 

(c)  implementation 

JL  G-  The  phase  in  which  module  testing  occurs  is 

(a)  reqi/irements  analysis  &  specification  (d)  maintenance 

(b)  design  (e)  all  of  these 

(c)  implementation 
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JL  H.  The  components  of  a  well  designed  software  system  will  have  a _ level 

of  cohesion  and  a _ level  of  coupling. 

(a)  low,  low  (b)  low,  high  (c)  high,  low  (d)  high,  high 

I.  A  structure  chart  does  ggt  show 

(a)  interfaces  between  modules  (d)  functions  of  modules 

(b)  the  modules  in  the  system  (e)  execution  order 

(c)  module  hierarchy  (who  calls  who)  (f)  g|l  these  are  shown 

*  JL  Black  box  testing  often  reveals  errors  in  the  interfaces  between  modules. 

(a)  true  (b)  false 

jL  K.  Traditionally,  software  maintenance  activities  consume  more  resources  than 
software  development  activities. 

(a)  True  (b)  False 

Jg_  L.  A  structured  analysis  model  of  a  software  system  (context  diagram,  data  flow 
diagrams,  process  specifications,  data  dictionary)  is  an  example  of 

(a)  process  documentation  (c)  both  (a)  and  (b) 

(b)  product  documentation  (d)  neither  (a)  nor  (b) 

JEL  The  users  manual  for  a  system  is  an  example  of 

(a)  process  documentation  (c)  both  (a)  and  (b) 

(b)  product  documentation  (d)  neither  (a)  nor  (b) 

_g.  N.  The  purpose  of  a  review  is  to  identify  and  correct  errors  in  the  reviewed  item, 
(a)  True  (b)  False 

*  _A_  O.  In  order  to  determine  whether  a  diild  data  flow  diagram  is  balanced  with 

respect  to  its  parent  data  flow  diagram,  one  would  need  to  look  in  the  data 
dictionary. 

(a)  True  (b)  False 

3.  P'  Are  the  Gazebo  Lottery,  Kiosk  Vending  Machine,  and  Pavilion  Recycling 
Systems  %vicked  problems"? 

(a)  Yes  (b)  No 
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2.  (4  points)  Sommerville  says  "assuming  the  software  provides  the  required 
functionality,  there  are  four  key  attributes  which  a  well-engineered  software  system 
should  possess".  What  are  they? 

1)  Maintainable  3)  Efficient 

2)  Reliable  4)  Appropriate  uaar  Interface 

3.  (8  points)  (a)  Name  and  distinguish  between  the  three  categories  of  software 
maintenance.  Use  examples  to  make  sure  the  distinction  is  very  dear. 

1)  Corrective  •  correcting  defects  (EXAMPLES) 

2)  Perfective  (Enhancement)  -  adding  new  feature  (change  in  requirements), 
usually  at  users  request 

3)  Adaptive  -  modification  due  to  change  in  operational  anvlronment  of  system 

(b)  Which  type  of  maintenance  would  you  expect  to  be  most  prevalent  in  the  first  few 
months  following  the  release  of  a  system?  Corrective 

(c)  Which  type  of  maintenance  would  you  expect  to  be  most  prevalent  after  the 
system  has  been  in  operation  for  a  couple  of  years?  Perfective  (enhancement) 

4.  (6  points)  (a)  Name  the  three  key  software  design  goals.' 

Maintainability,  testability,  reuseability 

(b)  Explain  how  coupling  and  cohesion  relates  to  each  of  these  design  goals. 

Design  consisting  of  highly  cohesive,  loosely  coupled  components  is  more 
maintainable,  more  easily  tested,  with  greater  potential  for  reuae.  Why? 

Cohesive  modules  perform  a  single  task;  loosely  coupled  modules  have 
minimal  dependencies  with  other  modules.  Therefore  when  maintenance  Is 
needed,  the  number  of  modules  affected  la  minimized  and  thua  the  chance 
of  an  error/change  in  one  module  affecting  other  modules  is  lowered. 
Cohesive  modules  tend  to  be  more  general  and  perform  a  aingle  task  and 
thus  have  a  higher  probability  for  reuse. 

5.  (5  points)  Regarding  software  life  cycle  models: 

(a)  The  spiral  model  is  sometimes  characterized  as  a  "risk-driven"  model.  Explain. 

A  key  characteristic  Is  the  aseessment  of  risk  at  regular  stages  In  the  prp)ect 
and  the  initiation  of  actiona  to  address  the  risks. 

Risk  analysis  (kfentlfying  lod  addressing  them)  Is  done  before  each 
cycle;  review  procedures  to  assess  the  risk  is  done  at  the  end  of  eech  cycle. 
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(b)  in  general,  for  what  type  of  system  would  the  waterfall  model  be  most 
appropriate?  the  spiral  model? 

Waterfall  -  lequirsmerita  atable,  well  defined;  Le.  specification  riek  le  low, 
imie/no  need  for  risk  resolution.;  data  proceealnq  appNcatlons 

Sdrol  -  hkih  risk  avatama:  rMudraments  are  dHHftiilt  to  oki  down:  unstable 

wwweaa a^apaa  ^p^y^wa^waaa^pg  a^^^oao^a^^waa^paaai^p  wia^p  a^waa^a^waaa  anp  Bpaaa  ai^apwaag  waa a^pw^aae^WF 

(Schach)  toitemal  projects;  large  prplecla 

6.  (8  points)  (a)  Classify  each  of  the  following  as  F  (functional)  or  N  (non-functional) 
requirements.  For  any  non-functiormi  requirement,  indicate  which  of  the  three  types 
of  non-functional  requirement  it  is. 

N  All  requirements  specifications  documents  must  conform  to  DOD-2167A. 

Prooeaa 

F  The  system  must  retrieve  any  customer  account  given  customer  id  or 
name. 

F  The  system  must  display  any  customer  account  on  demand. 

(b)  Improve  the  following  requirements  statements  so  that  they  are  testable. 

The  HVAC  monitoring  system  must  significantly  reduce  electrical  consumption 
throughout  the  organization. 

The  HVAC  monitoring  ayatem  must  reduce  electrical  consumption  by  a 
minimum  of  15%  throughout  the  organization. 

The  system  should  be  easy  for  experienced  controllers  to  use  and  should  be 
organized  so  that  user  errors  are  minimized. 

Experienced  controllers  should  be  able  to  uae  aU  of  the  syalam  functions 
after  a  total  of  two  hours  training. 

After  this  training,  the  average  number  of  errors  made  by  experienced 
uaerea  should  not  exceed  two  per  day.  user  errors  are  mtoilmtaed. 
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7.  (6  points)  (a)  Distinguish  between  white  box  and  black  box  testing,  including  the 
purpose  of  each  and  the  relationship  between  the  two. 

Black-box-  functionai  laatinp:  looka  at  avatam  externally  (how  doaa  It  bahave 
to  given  Inputa);  taata  derived  from  apecificatlona 

White-box-  structural  teetlno: taata  relv on  knowledge  of  Internal  structure 

Relationship-  Both  are  neoeasary;  neither  aufRclant 

(b)  Briefly  name  and  describe  one  black  box  method. 

Equivalence  partitioning  -  Claaaea  (partitions)  of  Input  data  with  common 
properties  (system  should  respond  In  same  way  for  aN  members  of  the  dasa) 
are  identified  and  used  to  derive  test  cases.  System  tested  with  a  test  from 
each  partition. 

8.  (5  points)  It  is  desirable  in  a  software  development  project  to  provide  traceabilitv  of 
requirements  throughout  the  development  process. 

(a)  In  the  deliverables  required  of  the  Gazebo,  Kiosk,  and  Pavilion  project  teams,  was 
traceability  between  requirements  and  test  plan  documents  required?  Explain. 

Yes  -  refer  to  required  deliverables 

(b)  In  the  deliverables  required  of  the  Gazebo,  Kiosk,  and  Pavilion  project  teams,  was 
traceability  between  reouirements  and  design  documents  required?  Explain. 

No  -  refer  to  rsquirad  delivsrables;  while  this  is  desirable  it  was  not  rsquirsd 
In  your  deliverabies. 

9.  (6  points)  Explain  the  meaning  of  the  folkwving  data  dictionary  entries. 

(a)  digit- 1|2|3|4|5|6|7|8|9|0 

payment  -  '$'  +  {digitj^o  [•»■'.'  •!>  digit  +  digit } 

Payment  of  any  of  following  forms:  ($,  0-4  digits,  .xx  optional) 

$9999.99  $9999 
$999.99  $999 
$89.99  $99 

$9.99  $9 

$.99  $ 
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(b)  payment.method  ■  ca8h|check|money_order|charge_card 

Paymant  mathod  la  caah  or  chock  or  money  order  or  chaige  card 

(c)  CourseRequestForm  >  Name  -t-  Semester  {Course  ID  *  Kirs) 

-t-  [Dean  signature  *  overload*] 

Semester  >  Fall  |  Spring  |  Summer 

Course  request  form:  name 

semester  (Fall  or  Spring  or  Summer) 
Iteration  of  Courss  ID  and  Hrs 
optional  Dean's  signature 


Show  picture  of  It 


10.  (20  points)  Consider  the  foiiowing  problem  specification  for  a  car  registration  system. 

A  taxpayer  in  the  Hawaii  must  register  his/her  car  in  order  to  obtain  a.  iicense  plate. 
To  register  a  car,  the  owner  must  present  a  proof  of  ownership,  proof  of  insurance, 
and  payment  for  the  license  plate.  After  registration  material  is  completed,  the  owner 
is  provided  with  a  car  registration  and  a  license  plate. 

The  Hawaii  highway  patrol  (HHP)  also  makes  requests  to  the  car  registration 
system.  The  HHP  can  request  the  owner  of  a  particuiar  registration  number  or  the 
registration  number(s)  beionging  to  a  particuiar  owner. 

(a)  Draw  the  context  diagram. 

(b)  Draw  the  first-level  data  flow  diagram. 


See  attached  diagrams 

(a)  Considar  notation  &  general  guidalines 

(b)  Consider  notation  &  general  guidelines 
Consider  balancing  with  context  diagram 
Separate  registration  and  HHP  aarvices 

Separate  validation  of  registration  info  ft  producing  it 
SeiMrate  HHP  determining  owner  given  registration  ft  vice  versa 
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HAME: 


SEMESTER:  _  Pall 

_  Spring 

_  SuHMr 


Dean's  Signature  (for  course  overload) 
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TEST  1,  PART  1  -  TAKE-HOME 


The  following  questions  comprise  one-half  of  Test  1.  Your 
answers  are  due  at  the  start  of  class  on  Thursday,  March  4. 

Use  a  word  processor  where  appropriate.  Answer  in  con^lete 
sentences  and  paragraphs,  double-spaced.  25%  of  your  grade  for 
this  portion  of  the  test  will  be  based  on  your  writing. 

The  questions  cover  both  assigned  reading  and  in-class  lectures 

and  discussion.  Answer  in  vour  own  words. _ Use  direct  quotes 

sparingly  and  always  indicate  when  you  are  quoting  another  source 
and  cite  the  source.  When  in  doubt,  refer  to  the  AS&T  Language 
Skills  Handbook  for  clarification. 

You  are  to  work  on  this  test  individually.  While  discussing  the 
questions  with  others  to  clarify  them  is  permissible,  solutions 
are  to  be  done  individually. 


1.  Explain  how  both  the  waterfall  model  of  the  software  process 
and  the  prototyping  model  can  be  accommodated  in  the  spiral 
process  model . 

2.  Describe  what  is  meant  by  the  terms  cohesion,  coupling,  and 
adaptability  as  design  criteria.  Explain  why  maximizing 
cohesion  and  minimizing  coupling  leads  to  more  maintainable 
systems . 

3.  Develop  a  class  object  model,  using  the  notation  described  in 
class,  for  the  Recycling  Project  Description  attached. 

4.  The  design  of  a  spelling  checker  is  discussed  in  Appendix  A  of 
Sommerville  (section  4,  pages  617-619)  to  illustrate  design 
description  languages.  Document  this  design  by  producing: 

(a)  a  context  diagram; 

(b)  a  leveled  and  balanced  set  of  data  flow  diagreuns; 

(c)  a  data  dictionary;  and 

(d)  a  structure  chart. 
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RECYCLIMG  PROJECT  DESCRIPTIQM 


A  system  is  needed  to  control  a  recycling  machine  for  returnable 
glass  bottles,  plastic  bottles  and  metal  cans.  The  machine  can 
be  used  by  up  to  three  customers  at  the  seune  time  and  each 
customer  can  return  all  three  types  of  items.  These  items  come 
in  various  types  and  sizes.  The  machine  must  check  which  type  of 
item  was  turned  in  so  that  it  can  print  a  receipt.  A  receipt, 
which  can  be  taken  to  a  cashier,  will  be  printed  out.  The  total 
value  of  the  items  turned  in  will  be  printed  on  one  line  and  the 
value  of  each  item  type  will  be  printed  on  separate  types  for 
each  line. 

The  machine  has  to  be  maintained  so  there  is  information  for  the 
maintenance  operator  which  consists  of  the  total  quantity  of  each 
item  type  that  has  been  turned  in  since  the  last  time  the  totals 
were  cleared.  This  information  should  be  able  to  be  printed  out. 
In  addition  to  these  totals,  the  maintenance  operator  should  be 
able  to  change  the  values  assigned  to  individual  item  types.  The 
machine  has  numerous  mechanical  functions  which  can  go  awry.  The 
machine  has  an  alarm  which  indicates  that  an  item  is  stuck  or 
that  the  receipt  roll  is  out  of  paper. 

To  return  items  the  customer  first  presses  the  receipt  button  to 
clear  all  totals.  The  system  then  places  the  items  into  the 
correct  item  type  slots.  With  each  item  deposited  the  machine 
increases  the  daily  totals  and  the  customer  totals  for  that  item 
type.  The  customer  presses  the  receipt  button  again  to  indicate 
the  end  of  his  transaction.  The  action  prints  the  receipt  and 
updates  the  daily  totals. 

The  operator  needs  the  ability  to  turn  the  alarm  off,  print  the 
daily  reports,  and  clear  the  report  totals.  Not  only  can  the 
value  of  the  items  be  changed,  but  because  manufacturers 
regularly  change  their  packaging,  the  operator  must  be  able  to 
change  the  allowable  sizes  for  each  item  type.  When  items  are 
stuck  the  customer  is  prevented  from  inserting  more  items  but 
that  customers  totals  are  not  lost.  After  the  stuck  item  is 
cleared  from  the  machine,  the  customer  can  continue  to  insert 
items  which  are  added  to  his/her  previous  totals. 
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STUDY  GUIDE  FOR  TEST  1,  FART  2  -  IN-CLASS 


1.  Sommerville  says  "assuming  the  software  provides  the  required 
functionality,  there  are  four  key  attributes  which  a  well- 
engineered  software  system  should  possess*.  What  are  they? 

2.  Name  and  briefly  describe/compare  the  three  types  of  software 
maintenance  activities. 

3.  Feuniliarize  yourself  with  the  requirements  of  the  attached 
Client  Request:  Small  College  Registration  System. 

4.  What  are  the  fundamental  differences  between  object-oriented 
and  function-oriented  design? 

5.  Regarding  verification  and  validation: 

(a)  What  is  the  difference  between  verification  and  validation 
and  why  is  validation  a  particularly  difficult  process? 

(b)  What  is  the  difference  between  testing  and  debugging? 

(c)  Define  the  following  types  of  testing:  unit,  module,  sub¬ 
system,  system,  acceptance,  alpha,  beta,  regression. 

(d)  Understand  these  testing  strategies:  top-down,  bottom-up, 
thread,  stress. 

(e)  Are  V&V  and  Software  Quality  Assurance  synonyms?  Explain. 

6.  Understand  these  object-oriented  terms:  class,  object  (state, 
behavior,  identity),  abstraction,  encapsulation,  modularity, 
hierarchy  (2  types),  inheritance,  polymorphism. 

7.  Transform  analysis  is  a  strategy  for  obtaining  a  first-cut 
structure  chart  from  a  data  flow  diagram.  One  step  in 
transform  analysis  is  identifying  the  central  transform.  What 
is  the  central  transform  and  how  can  it  be  identified? 

8.  Regarding  configuration  management  (CM); 

(a)  What  is  CM  and  what  are  the  four  major  CM  activities? 

(b)  What  happens  when  something  is  placed  under  configuration 
control  (i.e.  becomes  a  configuration  item)? 

(c)  What  are  the  configuration  items  in  a  well -engineered 
software  project? 

9.  According  to  Sommerville,  would  a  good  software  development 
organization  have  a  Software  Quality  Assurance  (SQA)  Group 
responsible  for  SQA  throughout  the  organization  or  various  SQA 
tecuns,  one  associated  with  each  software  project?  Do  you 
agree  with  Sommerville?  Can  you  think  of  an  advantage  and 
disadvantage  of  each  type  of  SQA  organization? 
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CLIENT  REQUEST:  SMALL  COLLEC3E  REQISTRATIQM  SYSTEM 


The  Dean  of  the  Faculty  at  a  small  college  wants  to  automate 
their  student  registration  system.  Following  is  her  request. 

We  want  to  retain  many  of  the  features  of  our  current  manual 
registration  system  while  automating  some  of  the  paperwork. 
Specifically,  we  want  to  retain  the  interaction  between 
faculty  and  students  during  the  registration  process.  We 
visualize  the  following  process. 

Each  faculty  member  will  continue  to  participate  in 
registration.  Each  will  sit  at  a  table  in  the  student  center 
with  a  set  of  "slot  cards”  for  each  course  they  teach. 

They'll  have  one  slot  card  for  each  position  in  a  class  (i.e. 
if  the  maximum  enrollment  for  a  class  is  12,  then  there  will 
be  12  slot  cards  for  that  class) .  A  slot  card  contains  the 
course  number,  location,  time,  and  space  for  student  name  and 
instructor's  signature.  Each  faculty  member  also  has  a  blank 
class  roster  for  each  course  containing  course  number, 
location,  time,  and  spaces  for  names  of  students  in  the  class. 

A  schedule  booklet  is  sent  to  each  student  approximately  two 
weeks  prior  to  registration.  At  the  same  time  each  student  is 
sent  an  up-to-date  transcript. 

On  registration  day,  students  go  to  the  student  center  and 
pick  up  a  slot  card  for  each  course  they  want  to  take.  Before 
giving  them  a  slot  card,  the  faculty  member  looks  at  their 
transcript  (to  check  prerequisites,  etc)  and  takes  one  of  the 
following  actions: 

(a)  completes  a  slot  card  for  the  course  (adds  student  name 
and  faculty  signature) ,  adds  the  students  name  to  the 
class  roster,  and  gives  the  slot  card  to  the  student;  or 

(b)  tells  the  student  they  can't  take  the  course. 

When  finished,  students  turn  in  their  slot  cards  and 
instructors  turn  in  their  class  rosters.  The  (new)  automated 
system  is  then  used  to  officially  register  students.  The 
system  generates  a  schedule  and  bill  for  each  student,  an 
official  class  roster  for  each  instructor,  and  a  "discrepancy 
report"  for  each  student  or  instructor,  as  appropriate. 
Discrepancies  occur  in  two  ways:  first,  whenever  a  slot  card 
exists  for  a  given  student  but  that  student  does  not  appear  on 
the  class  roster  sulimtitted  by  the  instructor;  and  second, 
whenever  a  student  does  appear  on  the  class  roster  submitted 
by  an  instructor  but  a  corresponding  slot  card  is  not 
submitted. 
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CSCI  3250-201:  SOnwatE  ENGINEERING 


TEST  1.  PART  1  -  TAKE-IiC3ME 


The  following  questions  comprise  one-half  of  Test  1.  Your 
answers  are  due  at  the  start  of  class  on  Thursday,  March  4. 

Use  a  word  processor  where  appropriate.  Answer  in  complete 
sentences  and  paragraphs,  double-spaced.  25%  of  your  grade  for 
this  portion  of  the  test  will  be  based  on  your  writing. 

The  questions  cover  both  assigned  reading  and  in-class  lectures 

and  discussion.  Answer  in  vour  own  words. _ Use  direct  flUOteS 

sparingly  and  always  indicate  when  vou  are  quoting  another  source 
and  cite  the  source.  When  in  doubt,  refer  to  the  AS&T  Language 
Skills  Handbook  for  clarification. 

You  are  to  work  on  this  test  individually.  While  discussing  the 
questions  with  others  to  clarify  them  is  permissible,  solutions 
are  to  be  done  individually. 


1.  Explain  how  both  the  waterfall  model  of  the  software  process 
and  the  prototyping  model  can  be  accommodated  in  the  spiral 
process  model. 

2.  Describe  what  is  meant  by  the  terms  cohesion,  coupling,  and 
adaptability  as  design  criteria.  Explain  why  maximizing 
cohesion  and  minimizing  coupling  leads  to  more  maintainable 
systems . 

3.  Develop  a  class  object  model,  using  the  notation  described  in 
class,  for  the  Recycling  Project  Description  attached. 

4.  The  design  of  a  spelling  checker  is  discussed  in  Appendix  A  of 
Sommerville  (section  4,  pages  617-619)  to  illustrate  design 
description  languages.  Document  this  design  by  producing: 

(a)  a  context  diagram; 

(b)  a  leveled  and  balanced  set  of  data  flow  diagrams; 

(c)  a  data  dictionary;  and 

(d)  a  structure  chart. 
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A  system  is  needed  to  control  a  recycling  machine  for  returnable 
glass  bottles,  plastic  bottles  and  metal  cans.  The  machine  can 
be  used  by  up  to  three  customers  at  the  same  time  and  each 
customer  can  return  all  three  types  of  items.  These  items  come 
in  various  types  and  sizes.  The  machine  must  check  which  type  of 
item  was  turned  in  so  that  it  can  print  a  receipt.  A  receipt, 
which  can  be  taken  to  a  cashier,  will  be  printed  out.  The  total 
value  of  the  items  turned  in  will  be  printed  on  one  line  and  the 
value  of  each  item  type  will  be  printed  on  separate  types  for 
each  line. 

The  machine  has  to  be  maintained  so  there  is  information  for  the 
maintenance  operator  which  consists  of  the  total  quantity  of  each 
item  type  that  has  been  turned  in  since  the  last  time  the  totals 
were  cleared.  This  information  should  be  able  to  be  printed  out. 
In  addition  to  these  totals,  the  maintenance  operator  should  be 
able  to  change  the  values  assigned  to  individual  item  types.  The 
machine  has  numerous  mechanical  functions  which  can  go  awry.  The 
machine  has  an  alarm  which  indicates  that  an  item  is  stuck  or 
that  the  receipt  roll  is  out  of  paper. 

To  return  items  the  customer  first  presses  the  receipt  button  to 
clear  all  totals.  The  system  then  places  the  items  into  the 
correct  item  type  slots.  With  each  item  deposited  the  machine 
increases  the  daily  totals  and  the  customer  totals  for  that  item 
type.  The  customer  presses  the  receipt  button  again  to  indicate 
the  end  of  his  transaction.  The  action  prints  the  receipt  and 
updates  the  daily  totals. 

The  operator  needs  the  ability  to  turn  the  alarm  off,  print  the 
daily  reports,  and  clear  the  report  totals.  Not  only  can  the 
value  of  the  items  be  changed,  but  because  manufacturers 
regularly  change  their  packaging,  the  operator  must  be  able  to 
change  the  allowable  sizes  for  each  item  type.  When  items  are 
stuck  the  customer  is  prevented  from  inserting  more  items  but 
that  customers  totals  are  not  lost.  After  the  stuck  item  is 
cleared  from  the  machine,  the  customer  can  continue  to  insert 
items  which  are  added  to  his/her  previous  totals. 
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CSCI  3250-201:  SOFTWARE  ENGINEERING 


STUDY  GUIDE  FOR  TEST  1,  PART  2  -  IN-CLASS 


1.  Soinmerville  says  "assiunlng  the  software  provides  the  required 
functionality,  there  are  four  key  attributes  which  a  well- 
engineered  software  system  should  possess”.  What  are  they? 

2.  Name  and  briefly  describe/compare  the  three  types  of  software 
maintenance  activities. 

3.  Familiarize  yourself  with  the  requirements  of  the  attached 
Client  Request;  Small  College  Registration  System. 

4.  What  are  the  fundamental  differences  between  object-oriented 
and  function-oriented  design? 

5.  Regarding  verification  and  validation: 

(a)  What  is  the  difference  between  verification  and  validation 
and  why  is  validation  a  particularly  difficult  process? 

(b)  What  is  the  difference  between  testing  and  debugging? 

(c)  Define  the  following  types  of  testing:  unit,  module,  sub¬ 
system,  system,  acceptance,  alpha,  beta,  regression. 

(d)  Understand  these  testing  strategies:  top-down,  bottom-up, 
thread,  stress. 

(e)  Are  V&V  and  Software  Quality  Assurance-  synonyms?  Explain. 

6.  Understand  these  object-oriented  terms:  class,  object  (state, 
behavior,  identity) ,  abstraction,  encapsulation,  modularity, 
hierarchy  (2  types) ,  inheritance,  polymorphism. 

7.  Transform  analysis  is  a  strategy  for  obtaining  a  first-cut 
structure  chart  from  a  data  flow  diagram.  One  step  in 
transform  analysis  is  identifying  the  central  transform.  What 
is  the  central  transform  and  how  can  it  be  identified? 

8.  Regarding  configuration  management  (CM): 

(a)  What  is  CM  and  what  are  the  four  major  CM  activities? 

(b)  What  happens  when  something  is  placed  under  configuration 
control  (i.e.  becomes  a  configuration  item)? 

(c)  What  are  the  configuration  items  in  a  well -engineered 
software  project? 

9.  According  to  Sommerville,  would  a  good  software  development 
organization  have  a  Software  Quality  Assurance  (SQA)  Group 
responsible  for  SQA  throughout  the  organization  or  various  SQA 
teams,  one  associated  with  each  software  project?  Do  you 
agree  with  Sommerville?  Can  you  think  of  an  advantage  and 
disadvantage  of  each  type  of  SQA  organization? 
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rr.TRMT  REQUEST..  SMAO.  mt.T.BnR  PWQISTRATIQM  SYSTEM 


The  Dean  of  the  Faculty  at  a  small  college  wants  to  automate 
their  student  registration  system.  Following  is  her  request. 

We  want  to  retain  many  of  the  features  of  our  current  manual 
registration  system  while  automating  some  of  the  paperwork. 
Specifically,  we  want  to  retain  the  interaction  between 
faculty  and  students  during  the  registration  process.  We 
visualize  the  following  process. 

Each  faculty  member  will  continue  to  participate  in 
registration.  Each  will  sit  at  a  table  in  the  student  center 
with  a  set  of  "slot  cards"  for  each  course  they  teach. 

They’ll  have  one  slot  card  for  each  position  in  a  class  (i.e. 
if  the  maximum  enrollment  for  a  class  is  12,  then  there  will 
be  12  slot  cards  for  that  class) .  A  slot  card  contains  the 
course  number,  location,  time,  and  space  for  student  name  and 
instructor's  signature.  Each  faculty  member  also  has  a  blank 
class  roster  for  each  course  containing  course  number, 
location,  time,  and  spaces  for  names  of  students  in  the  class. 

A  schedule  booklet  is  sent  to  each  student  approximately  two 
weeks  prior  to  registration.  At  the  same  time  each  student  is 
sent  an  up-to-date  transcript. 

On  registration  day,  students  go  to  the  student  center  and 
pick  up  a  slot  card  for  each  course  they  want  to  take.  Before 
giving  them  a  slot  card,  the  faculty  member  looks  at  their 
transcript  (to  check  prerequisites,  etc)  and  takes  one  of  the 
following  actions: 

(a)  completes  a  slot  card  for  the  course  (adds  student  ncune 
and  faculty  signature) ,  adds  the  students  name  to  the 
class  roster,  and  gives  the  slot  card  to  the  student;  or 

(b)  tells  the  student  they  can't  take  the  course. 

When  finished,  students  turn  in  their  slot  cards  and 
instructors  turn  in  their  class  rosters.  The  (new)  automated 
system  is  then  used  to  officially  register  students.  The 
system  generates  a  schedule  and  bill  for  each  student,  an 
official  class  roster  for  each  instructor,  and  a  "discrepancy 
report"  for  each  student  or  instructor,  as  appropriate. 
Discrepancies  occur  in  two  ways:  first,  whenever  a  slot  card 
exists  for  a  given  student  but  that  student  does  not  appear  on 
the  class  roster  submitted  by  the  instructor;  and  second, 
whenever  a  student  does  appear  on  the  class  roster  sulxnitted 
by  an  instructor  but  a  corresponding  slot  card  is  not 
submitted. 
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CSCI-3250,  TEST  1  PART  II  HAME: 


1. 


(5  points)  (a)  Describe  the  four  key  attributes  of  well- 
engineered  software  according  to  Sonunerville. 


(b)  In  addition,  a  well -engineered  software  system  must 


2.  (6  points)  A  software  organization  has  successfully  developed 
and  marketed  a  word-processing  package.  Though  this  may  seem 
impossible,  imagine  that  they  have  done  such  a  thorough  job 
that  the  specifications  have  t>een  completely  met  and  tested 
and  there  are  absolutely  zero  defects  in  the  released 
software.  Under  these  conditions,  will  any  maintenance 
activity  be  expected?  If  so,  what  type?  Explain  thoroughly 
and  use  examples  to  illustrate  your  points. 
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3.  (5  points)  (a)  Define  coupling.  VRiat  is  the  major  design  goal 
for  coupling? 


(b)  Define  cohesion.  What  is  the  major  design  goal  for 
cohesion? 


(c)  What  is  relationship,  if  any,  between  coupling  and 

cohesion;  i.e.  do  they  have  any  effect- on  one  another? 


4.  (8  points)  There  are  two  types  of  hierarchical  relationships 
between  classes;  Generalization-Specialization  ("is  a”)  and 
Whole-Part  ("has  a"). 

(a)  Using  Rumbaugh's  notation  (as  on  the  ta)ce-home  test),  show 
an  example  of  each  type  of  hierarchy. 


(b)  What  is  the  Icey  difference  between  these  two  types  of 
hierarchical  relationships? 
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5.  (9  points)  (a)  Distinguish  between  verification  and  validation 
(V&V) .  Illustrate  by  giving  an  example  of  a  verification 
activity  and  an  example  of  a  validation  activity. 


(b)  Distinguish  between  V&V  and  software  quality  assurance. 


(c)  Distinguish  between  testing  and  debugging. 


(d)  Consider  this  statement;  One  of  the  goals  of  software 
testing  is  to  prove  that  a  program  works  correctly. 

(1)  Is  the  statement  true  or  false? 


(2)  If  true,  what  are  the  other  goals  of  software  testing? 
If  false,  what  are  the  goals  of  software  testing. 
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6.  (17  points)  For  each  item,  write  the  letter  of  the  correct 
answer  in  the  space  provided. 

_  A.  The  modules  of  a  well  designed  system  will  have  a  _ 

level  of  coupling  and  a  _  level  of  cohesion. 

(a)  high,  high  (c)  low,  high  (e)  none  of  these 

(b)  high,  low  (d)  low,  low 

_  B.  Stamp  and  control  coupling  should  always  be  avoided. 

(a)  True  (b)  False 


Factors  in  the  level  of  coupling 

(a)  amount  of  information  passed 

(b)  complexity  of  interface 

(c)  eunount  of  control  of  one 
module  over  another 


between  modules  include 

(d)  a  &  b,  not  c 

(e)  a  &  c,  not  b 

(f)  b  &  c,  not  a 

(g)  a  &  b  &  c 


_  D.  The  most  desirable  form  of  coupling  is 

(a)  control  (b)  content  (c)  data  (d)  stamp  (e)  common 


_  E.  The  most  desirable  form  of  cohesion  is 

(a)  coincidental  (d)  communicational  (g)  temporal 

(b)  logical  (e)  functional 

(c)  procedural  (f)  sequential 

_  F.  If  a  module  performs  several  different,  but  related, 

activities  then  its  cohesion  is  not  ideal.  The 
different  activities  could  be  related  due  to  "the  data 
of  the  problem",  "due  to  time",  or  "due  to  falling  in 
some  general  category."  Which  is  most  preferable? 

(a)  related  by  general  category  (c)  related  by  time 

(b)  related  by  data  (d)  all  equally  bad 


_  G.  By  itself,  a  structure  chart  can  give  one  a  pretty  good 

idea  of  the  coupling  and  cohesion  of  the  system. 

(a)  True  (b)  False 


_  H.  DFD's  are  _  documents;  structure  charts  are 

_ documents . 

(a)  analysis,  analysis  (c)  analysis,  design  (e)  none  of 

(b)  design,  design  (d)  design,  analysis  these 

_  I.  Which  is  not  shown  by  a  structure  chart? 

(a)  modules  within  system  (d)  module  hierarchy 

(b)  interfaces  between  modules  (e)  function  of  modules 

(c)  execution  order  of  modules  (f)  all  are  shown 

_  J.  The  detection  of  errors  associated  with  the  interfaces 

between  modules  is  a  goal  of  which  type  of  testing? 
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(a)  module  (c)  validation  (d)  system 

(b)  integration  (d)  regression 


K.  A  final  set  of  tests  to  ensure  that  the  software  meets 
all  requirements  is  called  _____________  testing. 

(a)  module  (c)  validation  (d)  system 

(b)  integration  (d)  regression 


L.  Errors  are  often  introduced  while  performing  perfective 
maintenance.  The  type  of  testing  designed  to  detect 
such  errors  is 

(a)  module  (c)  validation  (d)  system 

(b)  integration  (d)  regression 

M.  Advantages  of  top-down  testing  include 

(a)  allows  early  verification  of  overall  control  logic 

(b)  makes  providing  of  test  cases  easier 

(c)  allows  early  verification  of  major  module  interfaces 

(d)  a  and  b  only  (f)  b  and  c  only  (h)  none  of 

(e)  a  and  c  only  (g)  a,  b,  and  c  the  above 


N. 


_  is  the 

respond  to  the  same 

(a)  abstraction 

(b)  behavior 

(c)  class 

(d)  encapsulation 


ability  of  two  or 
message,  but  each 

(e)  hierarchy  - 

(f)  identity 

(g)  inheritance 

(h)  object 


more  classes  to 
in  its  own  way. 

( i )  polymorphi sm 

(j)  state 

(k)  none  of  these 


O.  _  is  a  set  of  objects  with  a  common  structure 

and  a  common  behavior. 

(a)  abstraction  (e)  hierarchy  (i)  polymorphism 

(b)  behavior  (f)  identity  (j)  state 

(c)  class  (g)  inheritance  (k)  none  of  these 

(d)  encapsulation  (h)  object 


P.  _  is  ignoring  certain  details  of  a  subject 

that  are  not  relevant  to  the  current  purpose  in  order  to 
focus  on  other  aspects  that  are. 

(a)  abstraction  (e)  hierarchy  (i)  polymorphism 

(b)  behavior  (f)  identity  (j)  state 

(c)  class  (g)  inheritance  (k)  none  of  these 

(d)  encapsulation  (h)  object 

Q.  _  is  the  act  of  grouping  into  one  object  both 

data  and  the  operations  that  affect  that  data. 

(a)  abstraction  (e)  hierarchy  (i)  polymorphism 

(b)  behavior  (f)  identity  (j)  state 

(c)  class  (g)  inheritance  (k)  none  of  these 

(d)  encapsulation  (h)  object 


CSCI-3250  SOFTWARE  ENGINEERING 
TEST  2  STUDY  GUIDE 


The  following  is  a  guide  to  review  material  covered  in  class  and/or 
in  assigned  reading.  You  are  not  to  turn  in  emswers  but  rather  use 
the  guide  in  preparing  for  the  4/20/93  test. 


1.  Sommerville  says  that  a  major  difficulty  is  establishing  large 
software  system  requirements  is  that  the  problems  are  usually 
"wicked  problems." 

a)  What  does  he  mean  bY  the  term  wicked  problem? 

b)  What  are  some  examples? 


2.  Distinguish  between  a  requirements  definition  auid  a 
requirements  specification?  Why  is  it  useful  to  draw  a 
distinction,  as  Sommerville  does,  between  a  requirements 
definition  and  a  requirements  specification? 


3.  Distinguish  between  functional  requirements  and  non- functional 
requirements? 


4.  Distinguish  between  a  logical  (or  essential)  model  and  a 
physical  model  of  a  system? 


5.  Regarding  a  Software  Project  Management  Plan  (SPMP) : 

a)  What  sorts  of  things  go  into  a  SPMP? 

b)  Is  it  a  managerial  document  or  a  technical  document? 

c)  What  is  the  relationship  between  the  deliverables  of  your 
teams  (on  the  class  project)  and  a  SPMP? 


6.  Consider  exeunples  such  as  that  described  on  page  58  (and 
Figures  3.6,  3.7,  in  writing/improving  requirement  definitions. 


7.  Consider  Exercises  5.2  and  5.8  (as  discussed  in  class). 

<  OVER  > 
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8. 


Regarding  software  reviews,  or  walkthroughs: 

a)  What  is  the  purpose? 

b)  Who  participates? 

c)  What  are  the  different  roles? 

d)  What  are  some  standard  guidelines? 

9.  Regarding  software  reliability: 

a)  What  is  it? 

b)  What  are  some  of  the  problems  with  specifying  reliability; 
why  is  it  difficult? 

c)  What  is  the  relationship,  if  any,  between  process  and 
product  reliability? 

d)  What  metrics  exist  for  assessing  software  reliability? 

10.  Describe  the  purpose  and  the  steps  of  statistical  testing. 

11.  Consider  Exercise  20.4  (as  discussed  in  class). 

12.  Everyone  should  be  generally  familiar  with  the  purpose . 
responsibilities,  and  deliverables  of  each  of  these  teams  on 
the  class  project; 

a)  configuration  management; 

b)  requirements; 

c)  users  manual; 

d)  test  plan; 

e)  preliminary  design. 

In  addition  everyone  should  have  detailed  knowledge  of  the 
purpose,  responsibilities,  and  deliverables  of  the  team(s)  of 
which  you  are  a  member. 
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1.  (15  points)  Concerning  walkthroughs  or  reviews: 

(a)  React  to  this  statement:  The  purpose  of  a 

review/walkthrough  is  to  review  a  work  product  in  order  to 
identify  and  correct  errors. 


(b)  Who  are  the  participants? 


(c)  When  is  it  appropriate,  during  a  project,  to  hold  a 
structured  walkthrough? 


(d)  Assume  you're  the  leader  of  a  project  team  and  you're 
preparing  a  "Guide  to  Structured  Walkthroughs"  for  your 
project  team.  List  5  key  guidelines  that  you  would 
include  on  preparing  and  conducting  a  structured 
walkthrough. 


1. 


2. 


3. 


4. 


5. 
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2.  (10  points)  (a)  Is  your  project  in  this  class  (the  Ccmqputer 
and  Information  Sciences  Student  Records  l^stem)  a  "wicked 
problem”  according  to  Sommerville's  definition?  Answer  yes  or 
no  and  then  justify  your  answer. 


(b)  Give  an  example  of  a  wicked  problem.  (NOTE:  the  example 
cannot  be  one  discussed  in  the  textbook.) 


3.  (10  points)  (a)  Distinguish  between  requirements  and 
specifications. 


(b)  Consider  the  requirements  phase  and  the  specification 
phase  of  a  software  development  project.  Would  it  make 
more  sense  to  combine  these  activities  into  one  phase, 
rather  than  treating  them  as  two  separate  phases?  Justify 
your  answer. 
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4.  (10  points)  (a)  What  is  the  difference  betvireen  functional 
requirements  and  non- functional  requirements? 


(b)  Give  an  example  of  a  functional  requirement  and  of  a  non¬ 
functional  requirement  from  the  class  project  (the 
Computer  and  Information  Sciences  Student  Records  System) . 


5.  (12  points)  Rewrite  each  requirements  so  that  it  may  be 
objectively  validated.  Malce  any  reasonable  assumptions. 

(a)  An  on-line  "HELP"  function  will  provide  users  of  the 

Computer  and  Information  Sciences  Student  Records  System 
with  appropriate  help. 


(b)  The  HVAC  monitoring  system  must  significantly  reduce 
electrical  consumption  throughout  the  organization. 


(c)  The  networ]c  must  be  set  up  at  a  reasonable  cost. 


(d)  The  system  should  Ise  easy  for  experienced  controllers  to 
use  and  should  Ise  organized  so  that  user  errors  are 
minimized. 
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6.  (6  points)  Briefly  explain  the  difference  between  a  logical 
and  a  physical  model  of  a  system. 


7.  (14  points)  Answer  each  of  the  following  True  or  False. 

_  A  Software  Project  Management  Plan  (SPMP)  is  a  managerial 

document  rather  than  a  technical  document . 

_  A  SPMP  for  the  class  project  (Computer  and  Information 

Sciences  Student  Records  System)  would  include  a 
description  of  the  team  organization  and  the 
responsibilities  of  each  team. 

-  A  SPMP  for  the  class  project  (Computer  and  Information 
Sciences  Student  Records  System)  would  include  a 
description  of  the  design  strategy  to  be  used  (for 
example,  structured  design  or  object-oriented  design) . 

_  A  SPMP  for  the  class  project  (Computer  and  Information 

Sciences  Student  Records  System)  would  include  a 
description  of  the  configuration  management  procedures. 

_  A  good  software  process  cannot  guarantee  cannot  guarantee 

a  reliable  software  product. 

_  According  to  Sommerville,  a  good  software  process  is 

essential  to  the  development  of  reliable  software. 

_  The  purpose  of  statistical  testing  is  to  estimate  software 

reliability. 
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8.  (15  points)  Regarding  software  reliability: 

(a)  Define  it. 

(b)  Distinguish  between  process  reliability  and  product 
reliability. 


(c)  Name  and  briefly  describe  four  metrics  used  to  assess 
software  reliability. 

1. 

2. 

3. 

4. 

(d)  For  each  of  the  metrics  described  in  part  (c),  to  what 
type  of  software  system  is  it  most  relevant? 
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CSCI-3250  SOPZMARE  ENGINEERING 
S*nJDY  GUIDE  FOR  TEST  3 


1.  Review  material  from  both  parts  of  Test  1  (take-home  part  amd 
in-class  part)  and  the  stu<^-guide  for  Test  1. 

2.  Review  material  from  Test  2  ajid  the  study  guide  for  Test  2. 

3.  Questions  regarding  your  second  project,  the  Computer  and 
Information  Sciences  Student  Records  System,  will  be  included. 

*************************************************************** 
The  following  question  will  definitely  be  on  the  test.  Prepare 
your  auiswer  in  advance,  using  a  word  processor,  and  subeiit  it 
when  the  test  is  given.  It  will  count  15  points  on  the  test. 
*************************************************************** 


Write  a  client  request  for  a  project  that  you  think  would  be 
suitable  to  serve  as  the  first  project  for  a  future  offering  of 
this  course  (e.g.  comparable  to  the  EMS-911  and  the  Recycling 
System  projects  used  in  this  class) .  The  client  request  must 
be  between  one-half  page  and  one-full  page  (single  spaced)  in 
length.  Your  solution  will  be  graded  on  writing, 
appropriateness  of  the  project,  and  originality. 


The  following  are  review  questions  for  material  covered  since 
the  second  test. 


5.  Regarding  software  safety:  a)  Define  these  terms: 
software  safety  mishap  hazard 

dcunage  risk  hazard  analysis 

primary  safety-critical  software 
secondary  safety-critical  software 

b)  Distinguish  between  software  safety  and  software 
reliability? 

c)  Could  a  software  system  be  reliable  but  not  safe?  Explain 
and  give  an  example.  Could  a  software  system  be  safe  but 
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not  reliable?  Explain  and  give  em  example. 

d)  One  method  of  analyzing  safety  requiranents  is  through 
Fault -Tree-Analysis  (FTA) .  What  is  the  purpose  of  FTA  and 
what  steps  are  involved? 


6.  Regarding  ethical  issues: 

a)  What  are  the  defining  characteristics  of  a  software 
professional? 

b)  Define  professional  computer  ethics. 

c)  Describe  one  case,  not  discussed  in  class,  which  involves  eui 
issue  in  computer  ethics  and  state  what  you  think  the 
ethical  issue  is. 
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CSCI“325Qi  TEST  3 _ _ 

1.  (7  points)  (a)  Define  configuration  management. 


(b)  What  does  it  mean  to  make  something  a  configuration  item? 


(c)  Name  four  configuration  items  from  CISSRS. 


2.  (10  points)  (a)  Name  and  describe  the  three  categories  of 

software  maintenance.  In  your  description,  make  sure  that 
the  distinction  between  them  is  made  clear. 


(b)  Which  type  of  maintenance  would  you  expect  to  be  most 
prevalent  in  the  first  six  months  following  the  release 
of  CISSRS?  Explain. 
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(c)  Which  type  of  maintenance  would  you  expect  to  be  most 
prevalent  after  CISSRS  has  been  in  operation  for  a  year? 
Explain. 


3.  (6  points)  We  have  discussed  several  software  life  cycle 

models,  including  the  waterfall  model  and  the  spiral  model, 

(a)  What  are  the  major  differences  between  the  waterfall 
model  and  the  spiral  model? 


(b)  For  what  type  of  system  would  the  waterfall  model  be 
appropriate?  Give  an  example. 


(c)  For  what  type  of  system  would  the  spiral  model  be 
appropriate?  Give  an  example. 


4.  (6  points)  In  object-oriented  analysis  and  design,  there  are 

two  types  of  hierarchical  class  relationships;  Whole-Part 
("has  a")  and  Generalization-Specialization  ("is  a"). 

(a)  What  is  the  major  difference  between  the  two? 


(b)  Using  Rumbaugh's  notation,  show  the  relationship  between 
students,  advisor-mentors,  clerical  staff,  and  super 
advisor-mentors  in  CISSRS. 
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5.  (16  points)  Briefly  distinguish  between: 

(a)  preliminary  design  and  detailed  design  (relative  to 
CISSRS) 


(b)  software  safety  and  software  reliability 


(c)  abstraction  and  encapsulation 


(d)  acceptance  testing  and  beta  testing 


6.  (4  points)  Classify  the  following  as  a  Verification  activity, 

a  Validation  activity,  or  neither. 

_  prototyping 

_  defect  testing 

_____________  the  Users  Manual  Review  for  CISSR.*i 

__________  the  Test  Plan  Review  for  CISSRS 
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7.  (7  points)  (a)  You've  been  asked  to  prepare  specifications 

for  structured  walkthroughs.  Write  4  specifications  that  you 
would  include. 


(b)  A  standard  guideline  is  that  identified  problems  are  not 
to  be  corrected  during  the  walkthrough.  Why? 


8.  (4  points)  (a)  What  is  a  hazard? 


(b)  What  is  the  output  of  hazard  analysis? 


(c)  When  is  hazard  analysis  undertaken? 


9.  (5  points)  (a)  What  are  the  defining  characteristics  of  a 

software  professional? 


(b)  Define  professional  computer  ethics. 


(c)  Describe  a  case,  not  discussed  in  class,  which  involves 
an  issue  in  computer  ethics  and  state  what  you  think  the 
ethical  issue  is. 
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10.  (10  points)  The  following  describes  how  a  small  college 
]x>okstore  orders  (buys)  and  sells  textboolcs. 

On  a  separate  sheet  of  paper: 

(a)  Construct  the  context  diagram; 

(b)  Construct  the  first  level  DFD; 

(c)  Circle  the  central  transform. 


The  Boolcstore  maintains  an  inventory  card  for  each  course  in 
the  catalog.  An  inventory  card  contains  the  title,  author, 
and  publisher  of  the  textlsoolc  currently  used  as  well  as  the 
number  currently  in  stoclc. 

In  April  the  Boolcstore  asks  each  department  to  provide  them 
with  the  following  information  for  each  course  they  teach: 

(a)  title,  author,  publisher  of  book  to  be  used  next 
year; 

(b)  expected  enrollment  in  the  course  next  year. 

In  June,  the  Bookstore  creates  a  Books  Needed  File  and  a  Buv 
Back  File.  The  Books  Needed  File  contains  the  title,  author, 
publisher,  and  "nvimber  needed"  for  each  book.  The  "number 
needed"  is  expected  enrollment  minus  the  number  in  stock. 

The  Buy  Back  File  contains  title,  author,  publisher,  and 
number  needed  for  each  book  for  which  the  expected  enrollment 
exceeds  the  number  in  stock. 

During  June  the  Bookstore  will  buy  books  from  students  as 
long  as  a  book  is  in  the  Buy  Back  File.  Of  course  each  time 
a  book  is  bought  from  a  student  the  number  of  copies  (of  that 
particular  book)  is  reduced  by  one  and  the  lx>ok  is  removed 
from  the  Buy  Back  File  when/if  the  number  needed  becomes 
zero. 

In  July  the  Bookstore  prepares  an  Order  List  containing  the 
title,  author,  publisher,  and  number  to  be  ordered  for  each 
book  that  is  still  needed.  The  Order  List  is  then  used  to 
create  an  individual  Book  Order  Form  for  each  publisher. 

These  Book  Order  Forms  are  sent  to  the  publishers. 
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SECOND  SEMESTER  EXAMINATION 

REVIEW  SHEET  FOR  TEST 

Ada 

classes  of  subsystems  resulting  from  ttie  analysis  phase 
as  a  design  tool,  support  for  reuse 
language  features  and  constructs 
packages,  package  specifications 
named  association 
overloading 
compilation  units 
context  clauses 

I/O,  files  (text,  sequential,  direct  access) 
program  structure 
data  types 

statements  (loops,  selection,  null,  block,  etc) 

program  units  (procedures  &  functions,  pacteges,  tasks,  generics) 

exceptions,  exception  handlers 

Requirements 

distinction  between  requirements  and  spedfications 
ways  to  evaluate  a  requirements  specification  (context  analysis,  walkthroughs, 
inspections,  requirements  validation  table) 
steps  in  developing  requirements 

validation  of  requirements,  requirements  validation  table,  formal  specifications 
2167a  as  a  standard  (2167a  language:  CSCI,  CSC,  HWCI,  CSU,  IRS) 

Structured  analysis  and  design 

transforms,  data  flows,  leveling,  balancing 
control  flows 

process  specifications  (what?  where  used?  methods,  notations) 
transform  analysis  and  transaction  analysis  (purpose,  technique,  input,  output) 

Design 

interface  design 
criteria  for  good  design 
coupling  (definition,  design  goals,  levels) 
cohesion  (definition,  design  goals,  levels) 
distinction  between  preliminary  design  and  detail  design  (goals, 
methods,deliverables  of  each) 
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ot^ect-oriented  design  (OOD) 

Distinguish  between  functionai  design  and  OOD. 

goais,  terminology,  characteristics  (classes,  sub-classes,  objects,  inheritance, 
information  hiding,  abstraction,  encapsulation,  methods,  aggregation) 
methods  of  identifying  objects 
Rumbaugh  notation 

Configuration  management  (CM) 

CM  activities 

configuration  items,  baselining 
impiementation  of  CM,  change  control  boards 

Verification  and  validation  (V&V) 
objectives 

distinction  between  verification  and  validation 
verification  -  static  and  dynamic 
validation  -  static  and  dynamic 
V&V  activities  at  each  development  phase 
testing 

relationship  to  V&V 

levels  of  testing  (unit,  integration,  acceptance) 
black-box,  white-box  methods 
test  plans 

test  oracle,  test  harness 
reliability  -  faults  and  failure 

Software  Quality  Assurance  (SQA) 
definition;  SQA  activities 
relationship  between  SQA,  V&V,  CM 
software  quality:  what  is  it?  components  of 
reviews  (walkthroughs,  inspections) 
purpose 

what  is  reviewed 
participants,  roles 
guidelines,  standards 


Project  2 

Responsibilities,  functions,  roles,  and  deliverables  of  all  teams. 
Application  of  lecture  and  reading  mateiial  to  project. 
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TmI 

1 .  (14  points)  For  each  definition,  write  the  letter  corresponding  to  the  term  (from  the 
list  below)  which  the  statement  describes.  A  term  cannot  be  used  more  l^an  once. 

_ 1 .  organizational  unit  within  company  that  reviews  each  request  for  a  change 

_ 2.  type  of  analysis  technique  us^  in  V&V  which  is  the  manual  or  automated 

examination  of  the  product 

_ 3.  process  of  evaluating  software  at  the  end  of  the  software  development 

process  to  ensure  compliance  with  software  requirements 

_ 4.  strategy  for  developir)g  test  cases  where  the  test  cases  focus  on 

requirements  (functionality,  input,  output) 

_ 5.  set  of  objects  with  a  common  structure  and  behavior 

_ 6.  relationship  among  classes  by  which  one  class  shares  the  structure  or 

behavior  defined  in  another  class 

_ 7.  principle  that  each  program  unit  should  only  be  allowed  access  to  data  or 

procedures  that  are  required  for  the  unit  to  perform  its  function 

_ 8.  the  only  way  objects  communicate  and  request  senrices  from  other  objects 

_ 9.  a  measure  of  the  dependency  between  components 

_ 10.  first  level  of  testing;  involving  individual  components 

_ 1 1 .  testing  designed  to  push  a  system  beyond  its  limits  in  order  to  observe  the 

system's  failure  behavior 

_ 12.  a  graphical  notation  for  representing  algorithms  in  detailed  design 

_ 13.  predicted  results  for  a  set  of  test  cases 

_ 14.  a  strategy  (to  create  a  structure  chart  from  data  flow  diagrams)  based  on 

the  idea  that  most  systems  have  a  transform  center 


TERMS  FOR  MATCHING  QUESTION  1 


A.  black  box  testing 

B.  Change  Control  Board  (CCB)  testing 

C.  class 

D.  cohesion 

E.  coupling 

F.  dynamic  analysis 

G.  exhaustive  testing 

H.  formal  analysis 

I.  information  hiding 

J.  inheritance 

K.  integration  testing 

L.  message 

M.  method 

N.  Nassi-Shnektorman  chart 


O.  object 

P.  static  analysis 

Q.  stress  testing 

R.  system  testing 

S.  test  orade 

T.  thread  testing 

U.  transaction  analysis 

V.  transform  analysis 

W.  unit  testing 

X.  validation 

Y.  verification 

Z.  white-box  testing 
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2.  (16  points)  Matching.  The  answers  at  the  right  may  be  used  more  than  once. 


_ 1.  only  programming  unit  in  whidi 

A.  constrained  array 

private  data  types  may  be 

B.  context  clause 

declared 

C.  derived  type 

_ 2.  programming  unit  which  is  used 

D.  Dfreet.lO 

as  the  main  program  or  driver 

E.  elaboration 

of  a  software  system 

F.  exception 

_ 3.  programming  unit  that  operates 

G.  exception  handier 

in  parallel  with  other 

H.  function 

programming  units 

1.  instantiation 

_ 4.  data  type  which  provides  a  new 

J.  overloading 

name  for  another  (potentially 

K.  package 

constrained)  data  type 

L.  procedure 

_ 5.  data  type  which  defines  a  distinct 

M.  raising  exception 

data  type  and  inherits  all  properties 

N.  separate 

of  its  base  type 

compilation 

_ 6.  processing  of  declarations  at 

0.  SequentiaIJO 

execution  time 

P.  subtype 

_ 7.  type  of  array  where  lower  and  upper  bounds 

Q.  task 

are  known  at  type  declaration  time 

R.  TextJO 

_ 8.  when  an  entity  in  Ada  has  more  than  one 

S.  unconstrained  array 

meaning 

_ 9.  the  process  of  detecting  an  exception  and  alerting  calling  subprogram 

_ 10.  predefined  Ada  package  which  provides  input-output  of  values  of  any 

nonlimited  type  in  a  binary  format  where  elements  are  read  and  written 
using  an  index 

_ 11.  predefined  Ada  package  which  provides  input-output  for  enumeration  types 

_ 12.  the  ability  to  compile  a  program  in  pieces  with  full  compiler  checking 

_ 13.  predefine  Ada  package  which  provides  input-output  of  values  in  human- 

readable  form 

_ 14.  only  programming  unit  whose  body  is  optional 

_ 15.  control  construct  that  promotes  flexible  response  to  run-time  events  such 

as  hardware  overflow 

_ 16.  new  program  unit  tailored  to  a  particular  applicatton  of  a  generic 
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3.  (13  points)  Short  answer  -  Ada. 

A.  (3  points)  Based  on  the  following  configuration,  list  the  order  that  the  programming 
units  must  be  compiled.  Distinguish  between  the  specification  and  body  of  the 
packages  when  listing  the  compilation  order.  If  the  following  configuration  is  illegal 
in  Ada.  indicate  "illegal"  and  specify  why  it  is  a  problem. 


package  BROWN  uses  packages  GREEN  and  YELLOW 
package  GREEN  uses  package  RED 
package  YELLOW  uses  packages  GREEN  and  BLUE 
package  RED  uses  package  BLUE 


B.  (4  points)  Indicate  the  possible  data  types  of  the  actual  parameter  which  matches 
the  formal  parameter  for  the  following  generic.  Also  list  the  operations  and 
attributes  which  are  available  inside  the  generic  body  for  this  formal  parameter. 

generic 

type  ELEMENT  is  (<>); 
package  EXAMPLE  is 

-  rest  of  generic  package 
end  EXAMPLE; 
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C.  (2  points)  How  many  exception  handlers  are  executed  if  MAIN  is  called? 
procedure  MAIN  is 

ERROR1.  ERROR2.  ERRORS  :  exception; 

procedure  B  is 
X :  integer: 
begin 

X  :■  1; 
if  X  •  i  then 
raise  ERROR2; 
eise 

raise  ERRORS; 

exception 

when  ERRORS  »>  raise; 

end  B; 

procedure  C  is 
begin 

B; 

exception 

when  ERROR2  »>  raise  ERROR1 ; 

when  ERROR1  «>  nuii; 

when  others  » raise  ERROR2; 

end  C; 

procedure  D  is 
begin 

C; 

exception 

when  ERRORS  «>  raise; 
when  ERROR1  «>  raise  ERRORS; 

end  D; 


begin 

D; 

exception 

when  ERRORS  ■>  nuil; 

when  ERRORS  ->  PUT_LiNE("ERROR  iN  PROCEDURE  C"); 
when  ERROR1  ->  PUT^LiNECERROR  IN  PROCEDURE  B"); 
end  MAIN; 
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D.  (4  points)  Discuss  the  tradeoffs  of  the  two  attemative  specifications  of 
ORDER.MAKER  below: 

generic 

type  ITEM  is  private; 

with  function  "<"  (LEFT,  RIGHT  :  ITEM)  return  Boolean 
is  <>; 

procedure  ORDER.MAKER  (l,J  :  in  out  ITEM); 


generic 

type  ITEM  is  (<>); 

procedure  ORDER.MAKER  (I.J  :  in  out  ITEM); 
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IV.  Short  discussiorr 

A.  (6  points)  (a)  Describe  the  relationship  between  coupling  and  cohesion.  (Do  not 
simply  define  coupling  and  cohesion). 


(b)  Distinguish  between  data  coupling,  stamp  coupling,  and  control  coupling? 


(c)  What  is  the  most  desirable  type  of  cohesion,  and  why? 
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B.  (12  points)  (a)  Distinguish  between  preliminar/  design  and  detailed  design.  Your 
answer  must  include  the  general  goals  and  the  general  deliverables  of  each. 


(b)  Name  and  briefly  describe  the  orelimi 
(Third  Eye), 
or 

(b)  Name  and  briefly  describe  the  detaile 
Eye). 


(c)  Describe  verification  and  validation  techniques  used  during  design. 
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C.  (15  points)  (a)  Explain  the  relationship  between  testing,  software  quality  assurance 
(SQA),  and  V&V,  including  the  distinction  between  them. 


(b)  Distinguish  between  white-box  and  black-box  testing,  including  the  purpose  of 
each  and  the  relationship  between  them. 


(c)  Briefly  describe  two  white-box  methods  and  two  black-box  methods. 
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D.  (5  points)  (a)  React  to  this  statement:  The  purpose  of  a  review/walkthrough  is  to 
review  a  work  product  in  order  to  identify  and  correct  errors. 


(b)  Who  are  the  participants  in  a  review/walkthrough  and  what  are  their  roles? 


E.  (5  points)  Describe  (a)  the  purpose  of  2167a,  (b)  its  relationship  to  requirements 
and  specifications,  and  (c)  a  description  of  three  of  its  major  components. 
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F.  (3  points)  Context  analysis  is  one  technique  used  to  elicit  complete  and  accurate 
requirements.  Describe  the  process  of  context  analysis  and  explain  what  it  adds  to 
the  process  of  abstracting  requirements  from  the  customer  request  into  a 
requirements  list. 


G.  (4  points)  Name  and  describe  two  ways  of  identifying  objects  that  were  discussed 
in  class. 
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TMtKEY 


1 .  (14  points)  For  each  definition,  write  the  letter  corresponding  to  the  term  (from  the 
list  below)  which  the  statement  describes.  A  term  cannot  be  used  more  than  once. 


_B_  1 .  organizational  unit  within  company  that  reviews  each  request  for  a  change 
_P_  2.  type  of  analysis  technique  used  in  V&V  which  is  the  manual  or  automated 
examination  of  the  product 

_X_  3.  process  of  evaluating  software  at  ttie  end  of  the  software  development 
process  to  ensure  compliance  with  software  requirements 
A,F  4.  strategy  for  developing  test  cases  where  the  test  cases  focus  on 
requirements  (functionality,  input,  output) 

_C_  5.  set  of  objects  with  a  common  structure  and  behavior 
_J_  6.  relationship  among  classes  by  which  one  class  shares  the  structure  or 
behavior  defined  in  another  class 

-L  7.  principle  that  each  program  unit  should  only  be  allowed  access  to  data  or 
procedures  that  are  required  for  the  unit  to  perform  its  function 
_L_  8.  the  only  way  objects  communicate  and  request  services  from  other  ot^ects 
_E_  9.  a  measure  of  the  dependency  between  components 
_VI^10.  first  level  of  testing;  involving  individual  components 

1 .  testing  designed  to  push  a  system  beyond  its  limits  in  order  to  observe 
the  system's  failure  behavior 

_N_12.  a  graphical  notation  for  representing  algorithms  in  detailed  design 
_S_13.  predict^  results  for  a  set  of  test  cases 

_V_14.  a  strategy  (to  create  a  structure  chart  from  data  flow  diagrams)  based  on 
the  idea  that  most  systems  have  a  transform  center 

TERMS  FOR  MATCHING  QUESTION  1 


A.  black  box  testing 

B.  Change  Control  Board  (CCB)  testing 

C.  class 

D.  cohesion 

E.  coupling 

F.  dynamic  analysis 

G.  exhaustive  testing 

H.  formal  analysis 

I.  information  hiding 

J.  inheritance 

K.  integration  testing 

L.  message 

M.  method 

N.  Nassi-Shneiderman  chart 


O.  obj^ 

P.  static  analysis 

Q.  stress  testing 

R.  system  testing 

S.  test  orade 

T.  thread  testing 

U.  transaction  analysis 

V.  transform  analysis 

W.  unit  testing 

X.  validation 

Y.  verification 

Z.  white-box  testing 
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2.  (16  points)  Matching.  The  answers  at  the  right  may  be  used  more  than  once. 


.K_1. 

_Q_3. 

_P_4. 

.C_5. 

-E_6. 

_A_7. 

J_8. 

M_9. 

b  10. 

R  11. 
N  12. 
R  13. 

K  14. 
F15. 

1 16. 


only  programming  unit  in  which 

A.  constrained  array 

private  data  types  may  be 

B.  context  clause 

declared 

C.  derived  type 

programming  unit  which  is  used 

D.  Direct.lO 

as  the  main  program  or  driver 

E.  elaboration 

of  a  software  system 

F.  exception 

programming  unit  that  operates 

G.  exception  handler 

in  parallel  with  other 

H.  function 

programming  units 

1.  instantiation 

data  type  which  provides  a  new 

J.  overloading 

name  for  another  (potentially 

K.  package 

constrained)  data  type 

L.  procedure 

data  type  which  defines  a  distinct 

M.  raising  exception 

data  type  and  inherits  all  properties 

N.  separate 

of  its  base  type 

compilation 

processing  of  declarations  at 

0.  SequentiaIJO 

execution  time 

P.  subtype 

type  of  array  where  lower  and  upper  bounds 

Q.  task 

are  known  at  type  dedaration  time 

R.  UxtJO 

when  an  entity  in  Ada  has  more  than  one 

S.  unconstrained  array 

meaning 

the  process  of  detecting  an  exception  and  alerting  calling  subprogram 

predefined  Ada  package  which  provides  input-output  of  values  of  any 
nonlimited  type  in  a  binary  format  where  elements  are  read  and  written 
using  an  index 

predefined  Ada  package  which  provides  input-output  for  enumeration  types 
the  ability  to  compile  a  program  in  pieces  with  full  compiler  checking 
predefined  Ada  package  which  provides  input-output  of  values  in  human- 
readable  form 

only  programming  unit  whose  body  is  optional 

control  construct  that  promotes  flexible  response  to  run-time  events  such 

as  hardware  overflow 

new  program  unit  tailored  to  a  particular  application  of  a  generic 
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3.  (13  points)  Short  answer  •  Ada. 

A.  (3  points)  Based  on  the  foliowing  configuration,  list  the  ordei  .  (he  progranuning 
units  must  be  compiled.  Distinguish  between  the  specification  and  body  of  the 
packages  when  listing  the  com^lation  order.  If  the  following  configuration  is  illegal 
in  Ada,  incHcate  "iilegaP  and  specify  wl^  it  is  a  problem. 

package  BROWN  uses  packages  GREEN  and  YELLOW 
package  GREEN  uses  package  RED 
package  YELLOW  uses  packages  GREEN  and  BLUE 
package  RED  uses  package  BLUE 


1. 

2. 

3. 

4. 

5. 

6. 


Blue  spec 

Rad — >  Blue 

Rad  spec 

A  A 

Green  spec 

1  1 

Yellow  spec 

1  I 

Brown  spec 

Green  Yellow 

bodies  In  any  order 

A  A 

I  I 

I  I 

~  Brown  — 


B.  (4  points)  Indicate  the  possible  data  types  of  the  actual  parameter  which  matches 
the  formal  parameter  for  the  following  generic.  Also  list  the  operations  and 
attributes  which  are  available  inside  the  generic  body  for  this  formal  parameter. 

generic 

type  ELEMENT  is  (<>); 
package  EXAMPLE  is 
••  rest  of  generic  package 
end  EXAMPLE; 


Discrete  data  type 

Attributes  'nrst,  'Ust,  *81100,  'Pied,  'Range 


Operations  ■,  /■ 
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C.  (2  points)  How  many  exception  handlers  are  executed  If  MAIN  is  caHed?  — i 
procedure  MAIN  is 

ERROR1,  ERROR2,  ERRORS  :  exception; 

procedure  B  is 
X :  Integer; 
begin 

X  1- 
if  X  -  i  then 
raise  ERRORS; 
else 

raise  ERRORS; 

exception 

when  ERRORS  «>  raise; 

end  B; 

procedure  C  is 
begin 

B; 

exception  2  ••• 

when  ERRORS  »>  raise  ERROR1; 

when  ERROR1  «>  null; 

when  others  » raise  ERRORS; 

end  C; 

procedure  D  is 
begin 

C; 

exception  3 

when  ERRORS  » raise; 
when  ERROR1  «>  raise  ERRORS; 

end  D; 


begin 

D; 

exception  4 

when  ERRORS  »  null; 

when  ERRORS  ->  PUT_LINE("ERROR  IN  PROCEDURE  C"); 
when  ERROR1  ->  PUT.LINEfERROR  IN  PROCEDURE  B"); 
end  MAIN; 
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D.  (4  points)  Discuss  the  tradeoffs  of  the  two  alternative  specifications  of 
ORDER_MAKER  below: 

generic 

type  ITEM  is  private; 

with  function  "<*  (LEFT,  RIGHT :  ITEM)  return  Boolean 
is  <>; 

procedure  ORDER_MAKER  (i.J  :  in  out  ITEM); 
generic 

type  ITEM  is  (<>); 

procedure  ORDER_MAKER  (I.J  ;  in  out  ITEM); 


As  a  generic  (template): 

First  is  broader,  more  flexible: 

(a)  allows  any  data  type,  Including  user  defined,  In  Instantiation 

(b)  providea 

Second  la  more  limitad  in  that  It  only  works  on  dlacrata  types 
(integer,  enumeration) 
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IV.  Short  discussion 

A.  (6  points)  (a)  Describe  the  relationship  between  coupling  and  cohesion.  (Do  not 
simply  define  coupling  and  cohesion). 

Cohesion  it  measure  of  internal  strength  of  a  component;  determined  by 
how  well  the  parts  of  a  component  contribute  to  single  purpose.  Goal  Is  to 
maximlie  cohesion.  Coupling  Is  a  measure  of  dependency  between  2 
components;  of  strength  of  Interconnections.  Goal  is  to  minimize  coupling. 

Strong  cohesion,  loose  coupling,  and  are  complementary  criteria;  go  haiKl- 
In-hand.  Increasing  cohesion  dscrsasss  coupling  &  vice-versa.  Sfrongly 
cohesive  components  are  highly  Independent;  loosely  coupled  components 
have  minimal  dependency.  Thus  by  maximizing  cohesion  and  minimizing 
coupling,  we  reduce  the  number  of  componanta  impacted  by  a  change  or 
defect;  thereby  simplifying  maintenance.  Stated  another  way,  we  reduce  the 
chance  that  a  change  to  one  component  will  require  a  change  to  others;  and 
we  reduce  "side-aftacts.'* 


(b)  Distinguish  between  data  coupling,  stamp  coupling,  and  control  coupling? 

Data  coupling  -  most  desirable;  only  parameters  communicated 

Stamp  coupling  -  communicates  at  Isast  one  data  structure  (and  the  called 
component  operates  on  some  but  net  all  of  the  data  structure's  components 

Control  coupling  -  communicate  at  least  one  element  of  control 


(c)  What  is  the  most  desirable  type  of  cohesion,  and  why? 

Functional  •  module  performs  single  task  and  each  part  of  the  module  is 
necessary  to  perform  that  task. 

Desirable  because  such  modules  are  easier  to  maintain  (leas  chance  of 
change  impacting  other  modules),  and  better  chance  of  reuse. 
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B.  (12  points)  (a)  Distinguish  between  preliminary  design  and  detailed  design.  Your 
answer  must  include  the  general  goals  and  the  general  deliverables  of  each. 

Preliminary  PfttilM — 

Move  from  problem  space  of  requirements  Expand  solution  space  detail! 
to  solution  space  sufficiently  to  be  easily 


general  SW  architecture  to  meet  specs 
components  &  their  interfaces 
data  structures 
user  interface  [Mynatt] 

OOD:  class  design 

oblects  and  Interfaces 
object  relations 

(b)  Name  and  briefly  describe  the  prelimir 

Preliminary _ 

Rumbaugh  object  model 
objects,  associations 
attributes,  operations 
Object  dictionary 

Object  name,  attributes. 

Method  description,  other  objects 
Object  requirements  traceability  matrix 
Ada  specifications 
User  interface  (menus,  reports) 


Expand  solution  space  details 
sufficiently  to  be  easily 
impiementable  on  computer 
expand  on  architecture 
algorithms  for  components 
data  structures  refined 


OOD:  Internal  object  structure 
data  structure  dictionary 
algorithms  for  methods 


for  project. 


Nassi-Shneidermann  charts 


Object  dictionary  Traceability  matrix 

Object  name,  attributes,  ds  to  object  attribute 

Method  description,  other  objects  NS  to  object  operations 

Object  requirements  traceability  matrix  Data  structure  dictionary 

Ada  specifications  Object  class,  Ada  package, 

User  interface  (menus,  reports)  ds  name  •  attr  covered 

ds  description  (a  la  DD) 

(c)  Describe  verification  and  validation  techniques  used  during  design. 

Reviews:  design  documents  (PDR,  DDR) 

project  V&V  plan 
test  plans 

Testing:  generation  of  test  plans  for  unit,  design  unit,  and  system 

testing;  generation  of  design-based  test  cases;  generation  of 
test  plan  for  acceptance  testing 
Traceability  of  design  (to  requirements;  to  acceptance) 


1.  Detailed  design 

2.  Use  object  model  to  trace  scenarios 


1.  Use  Nassl-Sh  to  trace  PD 

2.  Ail  objects  in  PD  used? 


3.  Check  matrix  correctness/completeness;  3.  Trace  matrix 


all  objects  related  to  at  least  one  other 
4.  Verify  with  end  user 


4.  No  Interface  modification 
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C.  (15  points)  (a)  Explain  the  relationship  between  testing,  software  quality  assurance 
(SQA),  and  V&V,  including  the  distinction  between  them. 

All  are  concerned  with  quality. 

SQA  encompasses  V&V;  V&V  encompasses  testing. 

Verification  -  does  system  meets  specifications  (build  product  right?); 
validation  •  does  Implemented  system  meet  customer  expectations  (build 
right  product?). 

(b)  Distinguish  between  white-box  and  biack-box  testing,  including  the  purpose  of 
each  and  the  relationship  between  them. 

White-box  (structural) 

tests  derived  using  knowledge  of  program's  Implementation;  focuses  on 
the  logic  of  the  module  to  determine  what  tests  to  run. 

Black-box  (functional) 

testa  derived  from  program's  specHleatlon;  designed  to  test  the  functions 
of  the  module.  For  a  given  Input,  does  It  produce  the  expected  output 

Are  not  altemative  approaches,  but  are  complementary,  designed  to  uncover 
different  types  of  defects.  Both  are  necessary;  neither  whlte^x  nor  black¬ 
box  is  sufficient  by  itself.  White-box  testing  examines  the  existing  code  and 
thus  cannot  discover  extra  fuctlona  included  in  code  but  not  included  in 
requirements.  Biack-box  can't  be  complete. 

(c)  Briefly  describe  two  white-box  methods  and  two  black-box  methods. 
White-box  (structural) 

-  Statement  coverage  -  every  statement  executed  at  least  once 

-  Decision  coverage  -  every  branch  traversed  at  least  once 

-  Condition  coverage  -  each  condition  In  a  decision  takes  on  ail  possible 
values  at  least  once 

-  Path  coverage  -  every  path  traversed  at  least  once 
Black-box  (functional) 

Equivalence  partitioning  -  involves  determining  which  input  classes  have 
common  properties  (are  similar  on  some  relevant  dimension);  then 
dividing  inputs  and  outputs  into  equivalence  partttions;  and  testing 
one  item  from  each  partition. 

Cause-effact  strategy  -  tests  combinations  of  inputs;  causes  (inputs)  and 
effecta  (outputs)  are  identified. 

Boundary  values  stratsgy  -  involves  Idsntifying  and  testing  conditions 
directly  on,  above,  and  below  the  edges  of  input  equivalence  claases. 
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D.  (5  points)  (a)  React  to  this  statement;  The  purpose  of  a  review/Walkthrough  is  to 
review  a  work  product  in  order  to  identify  and  correct  errors. 

Statement  inaccurate;  purpose  Is  to  Identify  but  ofll  to  correct  errors. 
Reviews  are  QA  activities;  intended  to  identify  problems;  to  collectively 
review  a  work  product  to  assure  that  it  meets  requirements  and  standards. 

(b)  Who  are  the  participants  in  a  review/waikthrough  and  what  are  their  roles? 

Review  leader/  evaluate  Herns  for  readiness 
moderator:  distribute  materials  in  advance 
review  material  prior  to  meeting 
schedule  review,  prepare  agenda 
Recorder:  record  important  issues  raised  in  review 

Producer:  walks  through  product 

Reviewers  review  material  prior  to  meeting;  prepare  list  of  Hems 

reader:  misunderstood  and  Hems  incorrect 

E.  (5  points)  Describe  (a)  the  purpose  of  2167a,  (b)  its  relationship  to  requirements 
and  specifications,  and  (c)  a  description  of  three  of  its  major  components. 

(a)  Purpose  •  2167a  is  DoD's  software  development  process  standard. 

Treats  software  development  as  a  milestone  driven  project.  Milestones 
are  generally  documents  or  clearly  specified  events.  2167a  characterizes 
several  processes  separated  by  the  completion  of  milestones. 

(b)  SRS  •  distinguish  between  requirements  &  specifications 

•  requirements;  classify  (mandatory,  desirable,  uneseential,  stabilHy) 

•  specifications  •  defauR  condRions,  handle  errors 

(c)  SRS  •  software  requirements  specRication 
IRS  -  interface  requirements  specRication 
CSCI  -  computer  software  Cl 

HWCI  -  hardware  Cl 

CSC  -  computer  software  component 

CSU  -  computer  software  unR 

Systems  contain  segments,  segments  contain  configuration  Rems, 
configuration  Rems  contain  configuration  components  and  components 
contain  unRs. 
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F.  (3  points)  Context  analysis  is  one  technique  used  to  elicit  complete  and  accurate 
requirements.  Describe  the  process  of  context  analysis  and  explain  what  it  adds  to 
the  process  of  abstracting  requirements  from  the  customer  request  into  a 
requirements  list. 

a)  Interview  customer/uaer  to  underetand  domain;  queationa  auch  aa: 

Why  deveiop  or  want  thia  ayatem? 

Where  wiii  it  be  uaed? 

Who  wiii  uae  it? 

What  are  the  economic  and  operationai  boundary  conditiona  of  ita 
uae? 

Thia  reauita  in  aoftware  needa. 

b)  Adda  itema  to  requirementa  iiat  which  wrere  not  expiicitiy  atated  in  the 
abatract;  i.e.  it  reveaia  conatrainta  and  unatated  requirementa. 


G.  (4  points)  Name  and  describe  two  ways  of  identifying  objects  that  were  discussed 
in  class. 

Linguistic  anaiysis:  nouns  are  potentiai  objects  and/or  attributes. 

verbs  are  potentiai  opreations 
abverbs  are  potentiai  constraints  on  operators 
Uae  cases  (scenarios;  sequence  of  events  in  interacting  with  system) 
Requirements  documents  (CD,  DFDs,  DD) 


70 


VII  Ada 


I  INTRODUCTION 

We  used  Ada  as  an  entire  life^cle  tool  throughout  the  two-semesters.  Our  approach 
of  a  coordinated  blending  of  lectures  and  projects  and  the  use  of  three  techniques  in 
teaching  Ada  -  a  spiral  approach,  program  reading,  and  a  detailed  examination  of 
language  features  -  enabled  students  to  see  Ada's  support  for  software  engineering  in 
and  beyond  implementation. 

Our  approach  uses  three  distinct  teaching  techniques;  a  spiral  approach,  program 
reading,  and  a  detailed  examination  of  language  features.  The  spiral  approach  to 
teaching  involves  the  gradual  introduction  and  application  of  concepts  and  the  revisiting 
of  them  in  increasing  depth  throughout  the  remainder  of  the  course  in  both  lectures  and 
project  activities.  Applying  this  spiral  approach,  Ada  is  introduced  as  software 
engineering  concepts  (e.g.,  abstraction,  information  hiding,  reusability,  and  maintainability) 
are  introduced.  With  each  concept,  the  language  features  of  Ada  which  support  that 
concept  are  also  introduced.  For  example,  during  the  discussion  of  maintainability 
students  are  shown  language  features  sudh  as  named  association  of  parameters, 
overloading,  packages,  and  separation  of  interface  specifications.  These  language 
features  are  presented  initially  through  program  reading  utilizing  small  examples  and  are 
discussed  only  in  relation  to  their  support  of  maintainability.  Only  after  students  have 
experienced  Ada  as  a  software  development  tool  do  they  examine  in  detail  the  language 
features  of  Ada.  Ada's  role  in  the  course  projects  is  described  in  the  following  section. 


II  THE  PROJECTS 

The  three  projects  provide  the  focus  for  the  two  semesters  and,  collectively,  provide 
students  with  a  variety  of  experiences  and  roles.  Ilie  first  project,  referred  to  as  the  small 
project,  begins  in  week  two  and  extends  through  week  seven  of  the  first  semester.  The 
second  project,  referred  to  as  the  extended  project,  is  introduced  in  week  six  of  the  first 
semester  and  extends  through  week  eleven  of  the  second  semester.  Finally,  the  third 
project,  referred  to  as  the  maintenance  project,  occupies  weeks  six  through  twelve  of  the 
second  semester.  Note  that  the  projects  overlap  and  all  are  completed  prior  to  the  end 
of  the  second  semester. 

In  order  to  provide  both  varied  and  realistic  experiences,  the  three  projects  differ  in  a 
number  of  significant  ways:  size  and  complexity,  project  team  organization,  information 
provided  to  the  teams  at  the  start  of  the  proje^,  deliverables  produced  by  the  student 
teams,  development  methodology,  tools,  controlling  disciplines,  and  the  use  of  reviews. 
A  brief  description  of  the  three  projects  follows. 

The  small  project  provides  an  early  and  quick  immersion  into  the  software  development 
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process.  Ada  is  introduced,  not  as  an  implementation  language,  but  as  a  specification 
tool  used  in  high  level  design.  During  this  project  students  used  Ada-TUTR  [1]  for  an 
initial  familiarization  with  Ada.  Ada-TUTR  provides  interactive  instruction  in  the  Ada 
programming  language,-  allowing  the  student  to  learn  at  his  own  pace.  On  a  PC,  it 
requires  a  hard-disk  or  a  3.5-inch  disk.  Access  to  an  Ada  compiler  is  helpful,  but  not 
necessary.  This  was  the  students  first  look  at  Ada.  We  did  not  discuss  the  details  of 
Ada  programming  style  until  the  extended  project. 

During  the  last  week  of  the  small  project,  the  students  are  introduced,  via  a  customer 
request,  to  the  extended  project  in  which  Ada  has  an  expanded  role.  The  project  is 
developed  using  Ada  in  the  high-level  design  and  as  the  implementation  language.  This 
project  serves  as  a  vehicle  both  to  revisit  concepts  in  depth  that  were  briefly  introduced 
in  the  small  project  and  to  introduce  and  utilize  new  concepts  including  detailed  design, 
configuration  management,  and  verification  and  validation.  We  adopted  the  Software 
Productivity  Consortium's,  Ada  Quality  and  Style:  Guideline  for  Professional 
Programmers,  as  the  programming  standard  for  the  course,  in  our  labs  we  use  Meridian 
Ada  for  the  PC. 

During  the  first  semester,  the  extended  project  is  taken  through  the  preliminary  design 
review.  Deliverables,  specified  in  Ada,  become  baseline  documents  for  detailed  design 
beginning  in  the  second  semester.  Tools  which  we  have  developed  to  facilitate  Ada 
implementation  (e.g.,  modified  Nassi-Shneiderman  diagrams  and  object  traceability 
matrix)  are  introduced  during  the  extended  project.  These  are  discussed  in  detail  in 
lecture  and  lab  materials. 

The  maintenance  project  overlaps  the  last  five  weeks  of  the  extended  project  and 
continues  one  week  beyond  it.  A  large  Ada  artifact  is  provided  and  students  must 
implement  the  change,  including  modification  of  all  appropriate  documents.  Previous 
semester’s  extended  projects  could  be  used  for  the  maintenance  exercise.  We  have  also 
used  Software  Maintenance  Exercises  for  a  Software  Engineering  Project  Course,  by 
Engle,  Ford,  and  Korson.  The  maintenance  project  constitutes  yet  another  circuit  in  the 
spiral  from  which  to  revisit  and  reinforce  significant  software  engineering  concepts,  but 
this  time  from  the  maintenance  perspective. 

Thus  Ada  is  integrated  into  the  project  experiences  as  well  as  into  the  lectures.  Early  in 
the  first  semester  it  is  introduced  through  program  reading  techniques  [2],  and  program 
reading  continues  throughout  (see  Section  IV).  Other  activities  include  the  writing  of  Ada 
high-level  design  specifications,  the  implementation  of  a  system  in  Ada,  and  maintenance 
on  an  existing  Ada  system.  This  approach  to  teaching  and  learning  Ada  enables  students 
to  see  Ada  as  more  than  an  implementation  language. 


Ill  THE  SPIRAL  APPROACH 
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Placing  a  small  project  at  the  beginning  of  the  course  permits  us  to  start  the  spiral 
approach  immediately.  Lectures  include  a  rapid  overview  of  the  elements  of  a  software 
development  life  cycle.  We  emphasize  design  and  introduce  Ada  as  a  specification 
language  through  program  reading.  These  concepts  are  also  emphasized  in  project 
deliverables  through  Ada  specifications  and  a  preliminary  design  review. 

An  extended  project  provides  an  opportunity  for  another  pass  through  the  lecture-project 
spiral.  During  this  phase  of  the  course  all  of  the  concepts  from  the  first  pass  through  the 
spiral  are  revisited  and  expanded  upon  in  both  lecture  and  project  deliverables.  While 
Ada  was  used  only  in  the  high-level  specification  of  the  small  project,  it  is  now  used  as 
a  requirements  specification  and  design  tool  as  well  as  an  implementation  language. 

Object-oriented  design  is  used  in  the  extended  project.  The  required  preliminary  design 
deliverables  include; 

1 .  An  object  diagram  using  Rumbaugh  notation, 

2.  A  class  dictionary, 

3.  An  object-requirements  traceability  matrix, 

4.  Ada  specifications  for  each  object  class,  and 

5.  Descriptions  of  all  major  user  interfaces. 

Traceability  is  extended  into  detailed  design  by  means  of  a  detailed  design  traceability 
matrix  (see  Lecture  31  and  associated  handouts).  We  created  this  matrix  to  provide 
traceability  between  preliminary  design,  detailed  design  and  implementation.  The  detailed 
design  matrix  first  provides  traceability  between  an  object's  attributes  and  its  data 
structures  and  between  those  data  structures  and  their  Ada  package  representation.  The 
matrix  also  provides  traceability  between  the  object's  operations,  the  detailed  design 
model  of  those  operations  and  the  Ada  padoge  embodying  those  operations. 

We  used  Nassi-Shneiderman  diagrams  as  the  detailed  design  model  for  these  operations. 
Nassi-Shneiderman  diagrams  provide  a  code  independent  notation  for  the  development 
of  algorithms  which  allows  the  students  to  think  through  the  solution  without  considering 
language  details.  We  created  Nassi-Shneiderman  extensions  to  include  language 
features  of  Ada  which  are  unique  and  which  have  no  associated  notation. 

During  the  extended  project,  program  reading  is  continued  as  examples  and  classroom 
exercises  provided  go  into  greater  depth.  Carefully  organized  use  of  self-paced  Ada 
tutorial  materials,  laboratory  experiences,  and  the  Ada  Language  Reference  Manual 
makes  it  possible  to  minimize  in-class  discussion  of  Ada  syntax.  In  lectures,  Ada's  role 
in  specification  and  design  is  emphasized.  The  use  of  accepted  controlling  techniques 
and  standards  introduced  in  the  small  project  is  also  reinforc^. 

The  maintenance  project  helps  students  see  the  utility  of  controlling  techniques  during 
original  development.  Ada's  impact  on  the  development  of  maintainable  artifacts  is 
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emphasized.  By  equating  maintenance  and  development,  the  students  revisit  most  of  the 
concepts  previously  discussed.  This  third  trip  through  the  spiral  makes  it  easier  for  them 
to  work  with  a  large  unfamiliar  artifact.  Mimy  students  find  this  somewhat  surprising  and 
rewarding. 


IV  PROGRAM  READING 

Program  reading  is  an  effective  technique  in  teaching  Ada  because  it  allows  the  students 
to  see  software  systems  developed  in  Ada  before  they  worry  about  the  implementation 
details  of  the  language.  In  program  reading,  students  become  familiar  with  a 
programming  language  through  first  readir^  programs  rather  than  writing  programs. 
Relatively  large,  well-designed  software  artifacts  written  in  Ada  are  examiriisd  by  the 
students.  The  students  see  not  only  the  source  code  but  also  supporting  documentation 
(e.g.,  analysis  model,  design  model).  Program  reading  emphasizes  the  design  of  the 
system  so  that  the  students  get  the  "big  picture"  of  how  effective  it  is  to  build  software 
using  Ada.  Language  features  are  pointed  out  but  discussed  only  in  relation  to  effective 
software  design.  For  example,  as  the  software  engineering  concept  of  abstraction  is 
discussed,  its  support  in  Ada  is  examined  through  program  reading.  Program  reading  is 
also  consistent  with  the  spiral  approach  since  it  allows  the  software  to  be  examined  in 
increasing  detail  as  the  students'  knowledge  increases. 

V  DETAILED  EXAMINATION  OF  LANGUAGE 

The  detailed  examination  of  language  features  is  the  last  technique  used  to  teach  Ada. 
Only  after  students  have  experienced  Ada  as  an  analysis  and  design  tool  are  they 
introduced  to  Ada  as  an  implementation  tool.  This  approach  Is  particularly  applicable  to 
Ada  because  of  its  support  throughout  the  life  cycle  while  most  other  programming 
languages  are  merely  implementation  tools.  Most  of  the  language  features  examined  at 
this  time  have  already  been  demonstrated  to  the  students  through  the  program  reading 
or  examples  which  supported  the  software  engineering  concepts  and  topics  discussed  in 
the  lectures.  Because  of  this  familiarity  with  the  language,  the  students  move  very  quickly 
through  the  implementation  details.  Because  the  details  were  covered  so  quir^ly,  one 
of  the  students,  Mitchell  Moses,  developed  an  Ada  reference  card  to  help  his  team 
members  remember  the  language.  He  has  graciously  consented  to  allow  us  to  include 
the  reference  card  for  your  use. 
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Ada  Language 

Progrcunmer '  s  Quick  Reference  Card 


Scalar  Data  Types 

Type _ Attributes 

boolMn 

character  Succ , Prad , Poa , Val 
anuneratlon 

Firat , Laat , Succ , Pred , Poa , Val 
float  Digits, Small. Large 

integer  Firat , Last 


Use  g£.  Sg.fllflr  Types 

Found  :  boolean; 

Flag  :  boolean  :>  True; 

Letterl  :  character 
Letters  :  character  'A'; 

Text.IO  contains  a  generic  package 
called  Enumeration_IO,  which  can  be 
instantiated  to  provide  10  routines 
for  enumeration  types. 


with  Text_I0;  use  Text_I0; 
procedure  Enum  is 

type  Days  is  (Mon,Tue,Wed,Thu,Fri, 
Sat, Sun) ; 

aubtype  WeekEnd  is  Days 
range  Sat.. Sun; 

package  Days_I0  is  new 

Enumeration_lO(Day8) ; 
package  WeekEnd.IO  is  new 
Enumeration_IO(WeekEnd) ; 

Today  !  Days; 

Tomorrow  :  WeekEnd; 
begin 

Today  : «  Fri ; 

Tomorrow  : *  Sat ; 

Put(Today);  --  write  current 
day 

Put (Tomorrow) ;  --  write  next  day 
end  Enums; 


Tax_Rate  :  float  0.12; 

Pi  :  constant  float  :>  3.14 

Count  :  integer; 

StartNum  :  integer  :=  1; 

Unary  Operators 

-  Arithmetic  Operators 

Operation _ Operator 

absolute  value  aba 

unary  plus  + 

unary  minus 

-  Boolean  Operators 

OBwatign _ Operator 

not  not 


Binary  Operators 
-  Arithmetic  Operators 
Operation  Operator 
exponentiation  ** 

multiplication  * 


division  ! 

modulus  aiod 

remainder  rent 

addition  4 


subtraction 


-  Boolean  Operators* 

Operation _ Operator 


and  and 
or  or 
exclusive  or  xor 
not  not 


'When  different  Boolean  operators  are 
mixed  in  the  same  expression, 
parentheses  are  required  for  clarity. 
Thus  the  expression: 

(i  >  j)  or  (k  >  1)  and  (k  •  i) 

is  invalid  and  must  be  written: 

((i  s  j)  or  (k  X  1))  and  (k  *■  i) 

When  using  the  binary  operators  and, 
or,  and  xor,  both  operands  are  always 
evaluated.  Short  circuiting  an  eval¬ 
uation  must  be  done  explicitly  using 
the  and  then  and  or  elae  operators. 
For  example: 

N:  Integer  :•  0; 

I,J:  Integer  :«  1; 

if  I  X  J  or  else  J  /  N  x  o  then  . . . 

short  circuits  Isefore  J  /  N  can  be 
evaluated  thus  preventing  a  divide  by 
0  run-time  error 

if  (TestCount  >  0)  and  then 

(TestTotal/TestCount  >  65)  then 

Fut_Llne( 'Passing  grade*); 

else 

Put_line(*Failing  grade*); 
end  if; 

short  circuits  before 
TestTotal/TestCount  can  be  evaluated 
and  cause  a  run-time  error. 


-  Relational  Operators 

Operation _ Operator 

equality  x 

Inequality  /* 

less  than  < 

less  than  or  equal  <x 

greater  than  > 

greater  than  or  equal  >■ 


-  Membership  Test 
Operators 

in,  not  in  are  used  to  determine  if 
the  value  of  an  expression  falls 
within  a  given  range  or  subtype.  For 
example: 

Hum  I  Integer; 

if  (Hum  in  1..100)  then 


given  the  subtype  declaration; 

subtype  SmallNums  is  integer  range 

1..100; 

the  condition  above  could  be  expressed 
as: 

if  (Hum  in  SmallNums)  then  ... 


Operator  Precedence 

highest  precedence  **,aba,not 
sniltiplying  *,/,mod,rem 

unary  adding  4,- 

binary  adding  4,-, a 

relational/membership  x, /.,<,<m,>,>x, 
in, not  in 

logical  and, or, xor, and 

then,  or  else 


Type  Conversions 

The  data  type  names  integer  and  float 
can  be  used  as  function  names  to 
convert  numeric  values  of  one  type  to 
the  other.  Float  values  are  rounded 
to  the  nearest  integer  when  converted 
to  integer.  For  example: 

integer (2. 4)  has  value  2 

integer (2.5)  has  value  3 

float(32/5)  has  value  6.0 

Structured  Data  Types 

_ Attributes 

array 

First , Last , Range, Length, First (n ) ' , 
Last(n) , Range (n) , Length (n) 

*  n  X  the  nth  array  in  a 
multidimensional  array. 

record 

Constrained, Flrst_Blt , Last.Bi t , 
Position 


Use  Of  Structured  Types 


Arrays 


tyipe  Line  is  array (1.. BO)  of 
character; 

type  List  is  array(1..5)  of  integer; 
A,B  :  Line; 

Matrix  :  array (1 . .4 , 1 . . 6)  of  float; 
Vector  :  List; 

Vector(4)  :x  15; 

Natrlx(2,3)  :x  4.7; 

A(4)  :x  B(7) ;  Single 

elements 

A  :x  B;  whole  arrays 

A(30..39)  :x  B(50..59):  10  element 

slices 

A  :•  (1. .80  x>  '  ■ ) ; 

B  :x  (1..5  x>  'A',  othersx>  •  • ) ; 

Unconstrained 

type  Vector  is  arrw( integer  range  <>) 
of  integer; 

type  Char.Count  is  array (character 
range  <>)  of  integer; 
subtype  :  Thousand  is  integer  range 
1. .1000; 

Ten  :  Vectord.  .10)  ; 

Kilo  :  Vector (Thousand) ; 

Ten(5)  :x  Tan(2)  *  Kilo(900): 

Use  of  Structured  Types  continues  on 
back  side  xxxxk> 


typa  Katrlx  is  array(intttg«r  rang*  <>, 
integer  range  <>)  of  float* 


Control  Statements 


Strinoa 

FlXe^mne  :  atringd.  >20)  * 

BrrMag  :  conatant  atring  :>  error 
file  not  found*: 

Line  :  atringd.  .80)  : 

Ada  does  not  have  variable  length 
strings,  necessitating  extensive  use 
of  array  slices.  For  example: 

Put (’Please  type  your  name:  *); 
(iet_i,lne( Line, Length)  ; 

Lined.  .Lengths 6)  :»  "Hello  *  a 
Lined.  .Length)  : 

Put ( Line d..Length+6));  New_Linej 


Records 

Hgn-Pitcrimitunt  BBtMda 

type  OigitString  is  arrayd..9)  of 

character  range  ' 0 ' . . ‘ 9 ' : 

type  Partlnfo  is 
record 

PartNum  :  OigitString; 

Description  :  strlngd.  .50) : 

Price  :  float: 

InStocIc  :  Integer  :=  0; 
end  record; 

type  Dayinfo  is 
record 

Month:  integer  range  1..12: 

Day:  Integer  range  1..31: 

year :  integer  range  0 . . 3  0  0  0 ; 
end  record: 


type  SqMatrix  (n  :  Integer)  is 
record 

Mat  :  Matrlxd.  .n.l.  .n) ; 
end  record; 

NewAcet  :  CreditLine(2000) ; 
Interview  :  Meeting; 

Lunch  :  Meetlng(1200,Wed) ; 
Line  :  Buffer; 

ShortLine  :  Buffer (40): 
LongLine  :  Buffer(2S6): 

Grid  :  SqMatrix (5): 


variant  Reeor^  ,  , 

type  Employeeinfo  (PayType  :  integer) 
is 

record 

Name  :  atringd.  .30) ; 
Address  :  stringd.  .40) ; 
case  PayType  is 
when  1  I  2  s> 

Wages  :  float; 

Hours  :  float; 

OTlme  :  float; 
when  3 . . 10  «> 

Rate  :  float; 

Sales  :  float: 
idMn  11  s> 

Salary:  float; 

%ihen  others  •> 
null; 

end  record; 


Selection 
if  (Score  >  60)  then 
status  :>  passing: 

else 

status  :>  failing; 
if; 


case  Score  is 

when  90..100>>  Grade  :«  'A'; 
when  80..89a>  Grade  :«  'B'; 
when  70..79«>  Grade  :«  'C: 
when  60..69»  Grade  :•  'D‘; 
when  0..59»  Grade  :•  'F‘: 
when  others»  null; 
end  case; 


Loop  Statements 
lo(9 

Count  :•  Count  +  1; 

Put (Count, 3) ; 
exit  when  (Count  •  10); 
end  loop; 

while  (Count  <  10)  loop 
Count  :>  Count  +  1; 

Put  (Count,  3)  ; 
and  loop; 

for  Count  in  1..10  loop 
Put (Count, 3) ; 
end  loop:* 


type  EmployeeData  is 
record 

Name:  stringd .  .20) ; 
BirthDate:  Dayinfo; 

Address:  stringd .  .30)  : 
end  record; 

Parti,  Part2  :  Partlnfo; 
EmployeeList:  arrayd.  .200)  of 

EmployeeData: 
Manager:  EmployeeData: 

Parti  :»  Part2; 

Employee ( 3 )  : >  Manager ; 
if  (Employee(i)  •  Employeed*!)  then 
Duplicate  :<  True; 
end  if: 

Parti . PartNumber  :«  ’OOOOiSOOS*; 
Part2.PartNum)5er (4)  :«  'S'; 
EmployeeList (3) .Name  :«  "John  Doe 

•  • 

Manager. BirthDate. Month  :«  9; 


record 

Celling  :  Integer  :>  Limit; 
Balance  :  float  :s  0; 
end  record; 

type  Days  is  (Mon.Tue.Wed, 

Thu, Fri, Sat, Sun) ; 

type  Meeting  (Hour:  integer  :■  1300, 
Day:  Days  :»  Fri)  is 

record 

M_tlme  :  Integer  :«  Hour; 
M_Day  :  Days  :«  Day; 
M_Place  :  stringd.  .30) ; 
end  record; 


Empl_l  :  Employeeinfo (1) ; 
Empl_2  :  Employeeinfo (7 ) ; 
Bmpl_3  :  Employeedl); 


Access  Data  Type  (Pointers) 

Type  Attribute 

access  Storage_Size 

Use  of  Access. Types 

type  CharPtr  is  access  Character; 

type  Vector  is  arrayd.. 4)  of  integer; 
type  VectorPtr  is  access  Vector; 

Cpt  :  CharPtr; 

Vpt  :  VeePtr;' 

'Access  variables  are.  Isy  default, 
initialized  to  the  access  value  null. 

•  allocating  memory 
Cpt  :>  new  character: 

Vpt  :«  new  Vector; 

-  referencing  access  types 
Cpt. all  :»  'x*; 

Vpt.all(3)  :•  4;' 

‘For  arrays  and  records,  selected  com¬ 
ponents  may  be  referenced  without  the 
•.all*  notation.  For  example:  Vpt(3) 
:>  4; 


"The  loop  control  variable  must  not  be 
declared  as  a  program  variable.  It  is 
implicitly  declared  Iv  its  use  in  the 
loop  construct,  and  its  scope  is 
restricted  to  the  loop  construct. 

Thus  it  redefines  any  identifier  of 
Che  same  name  within  its  scope. 


The  Block  Statement 

declare 

Temp  :  integer  :>  Num_l; 
begin 

Num_l  ! »  Num_2 ; 

Num_2  :■  Temp: 
end;' 

'the  declarative  i«rt  may  be 
referenced  only  within  the  block. 


Procedures /Funct ions 


procedure  Swap (a, b:  in  out  integer)  is 
Ten^  :  integer  :•  a; 
begin 

a  : «  b; 
b  :•  Temp; 
end  Swap; 

function  Is_Digit (Char  :  in  character) 

return 

boolean  is 
begin 

return  (Char  in  ‘0'..'9'): 
end  Is_Digit; 


type  Buffer  (Size  :  integer  :-  80)  is 
record 

Contents  :  stringd.  .Size) ; 
Location  :  integer  :>  0; 
end  record; 


VIII  RESOURCES 


a.  Software  Engineering  Bibliography 


BOOKS 


This  bibliography  consists  of  a  list  of  severai  software  engineering  text  books  which  we 
have  found  useful.  Also  included  are  some  books  related  to  particular  software 
engineering  issues  discussed  in  the  course.  Recently,  Wiley  Intersdence  has  published 
the  Encydooedia  of  Software  Enoineerino.  edited  bv  John  Marchintak.  It  is  a  useful 
resource  for  most  topics  discussed  in  the  course.  Foliowing  the  list  of  texts,  is  a  list  of 
artides  arranged  by  subject. 

Abdel-Hamid,  Tarek,  et  ai. 

Software  Project  Dvnamica:  An  Integrated  Approach.  Prentice  Hall.  Inc.,  1991. 
Arthur,  Lowell  J., 

Software  Evolution:  The  Software  Maintenance  ChaHenoe.  John  Wiley 
&  Sons,  1988. 


Bell,  Doug,  et  ai, 

Software  Er 
International,  1987. 


i:  A  Proorammino  Approach.  Prentice/Hall 


Berzins,  Vaktis,  et  al. 

Software  Engineering  with  Abstractions.  Addison-Wesley  Publishing  Co.,  1991. 
Boehm,  Barry  W., 

Software  Enoineerino  Economics.  Prentice-Hall,  Inc.,  1981. 

Booch,  Grady, 

Object  Oriented  Design  with  Applications.  The  Benjamin/Cummings 
Publishing  Company,  Inc.,  1991. 

Brooks,  Jr.,  Frederick  P., 

The  Mythical  Man-Month:  Essays  on  Software  EnoineeririQ. 

Addison-Wesley  Publishing  Co.,  1975. 


Burch,  John  Q., 


Systems  Analysis.  Deskin.  and  Implementation. 
Co.,  1992. 


Boyd  &  Fraser  Publishing 


Conger,  Sue. 

The  New  Software  Enoineerino.  Wadsworth  Publishing  Company,  1994. 


Fairley.  Richard. 

Software  Enginwriog  G 


i.  McGraw-Hill  Book  Co.,  1985. 


Fertuck,  Len, 

Systems  Analysis  and  Design  with  Case  Tools.  Wm.  C.  Brown  Publishers. 
1992. 

Gehani,  N..  et  al. 

Software  Specification  Techniques.  Addison-Wesley  Publishing  Co.. 

1986. 


Ghezzi,  Carlo,  et  al. 

FuDdam9nlal8..of  Softwaro  B 


Gilb,  Tom,  et  al. 

Principles  of  Software  Enoineerino  Ma 
Publishing  Co.,  1988. 


3  Prentice  Hall.  Inc.,  1991. 

:,  Addison-Wesley 


Higgins,  Dayid  A., 

Data  Structured  Software  Maintenance:  The  Wamier/Orr  Approach. 
Dorset  House  Publishing  Co.,  1986. 


Ince,  D.  C., 

Software  Ei 


.  Van  Nostrand  Reinhold  (International),  1989. 


Jacobson,  lyar, 

Object-Oriented  Software  Enoineerino:  A  Use  Case  Driyen  Approach. 
Addison-Wesley  Publishing  Co.,  1992. 


Jones,  Gregory  W., 

S2ftwaca.E 


iog,  John  Wiley  &  Sons.  1990. 


Keller,  Robert 

The  Practice  of  Structured  Analysis:  Explodino  Myths.  Yourdon  Press.  1983. 


Keyes,  Jessica. 

Software  Engineering  Productiyity  Handbook.  Windcrest/McGraw-Hill. 
1993. 


Kowai,  James  A 
Al 


Systems.  Prentice  Hall,  1988. 


Lamb,  Dayid  Alex, 

Software  Enoineerino:  Planning  for  Change 


[,  Prentice  Hall,  1988. 


Schach,  Stephen  R., 

Software  Engineering.  Second  Edition,  Richard  D.  Irwin.  Inc.,  and  Aksen 
Associates.  Inc.,  1993. 

Shooman,  Martin  L.. 
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pp.  1453-1461. 
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pp.92-99. 
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Software  Engineering  Environment  subsection 

Dart.  S..  R.  Ellison,  et  al.  "Software  development  environments."  IEEE  Computer, 
November  1987,  pp.  18-28. 

Kemighan  B.,  and  J.  Mashey.  "The  UNIX  programming  environment."  IEEE  Computer, 
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Software  Engineering  Techniques  section 

Bergland,  Q.  "A  guided  tour  of  program  design  methodologies."  IEEE  Software,  October 
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Tsichritzis,  D.  "Object-oriented  development  for  open  systems."  Information  Processing 
89,  Elsevier  Science  Publishers,  1989,  pp.  1033-1040. 

Object-oriented  analysis,  design  and  implementations.  An  example.  (Lecture  Notes) 
Formal  Methods  of  Software  Development  Section 

Gerhart.  S.  "Application  of  formal  methods:  Developing  virtuoso  software.”  IEEE  Software, 
7:5,  September  1990,  pp.  7-10. 

Cooke,  J.  "Formal  methods  —  mathematics,  theory,  recipes,  or  what?"  The  Computer, 
35:5,  1992. 

Hall,  A.  "Seven  myths  of  formal  methods.  IEEE  Software,  September  1990,  pp.  11-18. 

Galton.  A.  "Classical  Logic:  A  crash  course  for  beginners.  The  Computer,  35:5,  pp.424- 
430. 

Spivey,  J.  "An  introduction  to  Z  and  formal  specifications."  Software  Engineering  Journal, 
January  1989,  pp.  40-50. 


Future  Directions  section 

Musa,  J.  "Software  engineering:  The  future  of  a  profession.”  IEEE  Software,  January 
1985,  pp.  55-62. 

Shaw,  M.  "Prospects  for  an  engineering  discipline  of  software."  IEEE  Software,  November 
1990,  pp.  15-24. 

Cox,  B.  "Ranning  the  software  industrial  revolution."  IEEE  Soft¥vare,  7:6,  November  1990. 
pp.  25-32. 

Tsichritzis,  D.,  and  S.  Gibbs.  "From  Custom-made  to  Pre-a-Porter  software."  Object 
Management,  University  of  Geneva,  1990. 

Nierstrasz,  O.,  S.  Gibbs,  et  al.  "Component-oriented  software  development." 
Communications  of  tiie  ACM,  35:9,  September  1992,  pp.  160-165. 

Korson,  T.,  and  V.  Vaishnavi.  "Managing  emerging  software  technologies:  A  technology 
transfer  framework."  Communications  of  the  ACM,  35:9,  September  1992.  pp.  101-111. 


Humphrey,  W.  "Contracting  for  software."  Managing  the  Software  Process,  Addison- 
Wesley.  1989. 

Berztiss,  A.  "Engineering  principles  and  software  engineering."  Software  Engineering 
Education,  1992,  pp.  437. 
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Berzins,  V.,  and  Luqi.  Software  Engineering  with  Abstractions.  Addison-Wesiey,  1991. 

Byrne,  W.E.  Software  Design  Techniques  for  Large  Ada  Systems.  Digital  Press.  1991. 
31 4p. 


VII  RESOURCES 
b.  Ada  Bibliography 


There  are  two  sources  of  the  annotations  for  the  Ada  books  below.  One  source  is  the 
Ada  Books  iist  published  by  the  Ada  Information  Clearinghouse.  These  entries  are 
indicated  by  an  after  the  entry.  The  other  source  is  from  a  list  compiled  by  Mike 
Feldman,  education  cKrector  of  SIGAda. 

Andrews.  E.,  editors.  Concurrent  Programming  with  Ada.  Benjamin-Cummings.  1993.  * 

Atkinson,  C.,  et  al.  Ada  for  Distributed  Systems.  (Ada  Companion  Series)  Cambridge 
University  Press.  1988. 147p. 

Describes  the  final  report  of  the  Distributed  Ada  Demonstrated  (DIADEM)  project, 
which  studied  the  problems  and  developed  solutions  for  using  Ada  to  program  real¬ 
time.  distributed  control  systems.  Demonstrates  new  techniques  for  controiiing 
such  systems  from  a  distributed  Ada  program.  * 

Ausnit,  C.N.,  et  al.  Ada  in  Practice.  (Professional  Computing  Series)  Springer-Veriag, 
1985. 195p. 

Identifies  and  resoives  issues  reiated  to  Ada  usage  and  promotes  effective  use  of 
Ada  in  general  programming,  design  practice,  and  in  embedded  computer  systems. 
Contains  15  case  studies  that  cover  five  generai  areas  of  the  Ada  language: 
naming  conventions,  types,  coding  paradigms,  exceptions,  and  program  structure.* 

Barnes.  J.Q.P.  Programming  in  Ada  Plus  an  Overview  of  Ada  9X.  4th  edition.  Addison- 
Wesley,  1994.  622p. 

The  fourth  edition,  whiie  remaining  focused  on  the  current  ANSi  83  standard, 
reflects  the  imminent  Ada  9X  standard  in  three  ways:  ail  features  of  Ada  that  will 
be  affected  by  the  Ada  9X  standard  are  highlighted  with  icons  and  their  design 
rationaie  described  in  detail;  a  full  chapter  on  Ada  9X  provides  a  tutoriai  and 
summary  of  the  most  important  changes,  including  the  increased  support  for 
object-oriented  programming,  the  introduction  of  a  hierarchical  library  structure  and 
the  inclusion  of  protected  objects;  full  details  of  the  syntax  changes  are  provided 
in  the  appendices  for  easy  reference.  * 

Barnes,  J.  Programming  in  Ada.  3rd  edition.  Addison-Wesley.  1989.  494p. 

Discusses  Ada  using  a  tutorial  style  with  numerous  examples  and  exercises. 
Assumes  readers  have  some  knowledge  of  the  principles  of  programming.  Covers 
the  following:  Ada  concepts,  lexical  style,  scaler  types,  control  structures, 
composite  type,  subprogram,  overall  structures,  private  types,  exceptions, 
advanced  ty^,  numerics  types,  generics,  tasking,  external  interfaces.  * 

Barnes'  work  has  been  one  of  the  most  popular  ”Ada  books."  Some  students  And 


it  hard  to  see  how  the  pieces  fit  together  from  Barnes'  often  fragmentary  examples; 
K  is  difficult  to  find  complete,  fully-worked  out,  compilable  programs.  A  version  is 
available  with  the  entire  Ada  Language  Reference  Manual  bound  in  as  an 
appendix. 

Barnes,  J.  Programming  in  Ada.  2nd  edition.  Addison-Wesley,  1983.* 

Ben-Ari,  M.  Principles  of  Concurrent  and  DisPibuted  Programming.  Prentice-Hall  1990. 

(OS/concurrency) 

In  my  opinion,  this  is  the  best  introduction  to  concurrency  on  the  market.  Ada 
notation  is  used  for  everything,  but  the  focus  is  on  concurrency  and  not  on  Ada 
constructs  per  se.  I  liked  the  CoPascal  notation  of  the  first  edition  better,  but  this 
book  is  still  great.  A  software  disk  is  promised  in  the  preface;  I  had  to  work  quite 
hard  to  get  it  from  the  publisher,  which  finally  had  to  express-ship  it  from  England. 
The  software  comes  with  a  tiny  Ada-ish  interpreter,  complete  with  Pascal  source 
code,  adapted  from  Wirth's  Pascal/S  via  CoPascal.  There  are  also  some  real  Ada 
programs,  most  of  which  I've  tested  and  found  correct  and  portable. 

Booch,  G.  Software  Engineering  with  Ada.  3rd  ed.  Benjamin-Cummings,  1994. 

Introduces  Ada  from  a  software  engineering  vantage.  Addresses  the  issues  of 
building  complex  systems.  Includes  new  features  in  this  second  version:  a  more 
thorough  introduction  to  Ada  syntax  and  semantics,  an  updated  section  on  object- 
oriented  techniques  to  reflect  the  current  state  of  knowledge  and  improved 
examples  that  illustrate  good  Ada  style  for  production  systems  deveiopment.  * 

Booch,  G.  Software  Engineering  with  Ada.  (2nd  edition)  Benjamin  Cummings  1987. 
Another  of  the  classical  "Ada  books."  Introduces  Booch's  (X)D  ideas.  Not  for  use 
to  introduce  Ada  to  novices,  in  my  opinion;  there  are  some  nice  fuiiy-worked  case 
studies  but  they  begin  too  far  into  the  book,  after  iong  sections  on  design, 
philosophy,  and  language  elements.  The  earlier  chapters  contain  too  much 
fragmentary  code,  a  common  flaw  in  books  that  foilow  the  LRM  order. 

Booch,  G.  Object-Oriented  Design,  with  Applications.  Benjamin  Cummings,  1991. 

This  is  a  good  comparative  introduction  to  the  "object-oriented  ((X))"  concept.  The 
first  half  gives  a  balanced  presentation  of  the  issues  in  00  Design;  the  second  haif 
gives  nontrivial  examples  from  Ada,  Smalltalk,  C-t-f,  CLOS,  and  Object  Pascal. 
The  author  tries  to  sort  out  the  difference  between  object-bas^  (weak  inheritance, 
like  Ada)  and  object-oriented  (like  C^+)  languages.  My  only  real  complaint  is  that 
Booch  should  have  worked  out  at  least  some  of  his  case  studies  using  several 
different  languages,  to  highlight  the  similarities  and  differences  in  the  ianguage 
structures.  As  it  is,  each  case  study  is  done  in  only  a  single  language.  The  good 
news  is  that  the  book  is  remarkably  free  of  the  hyperbolic  claims  one  sometimes 
finds  in  the  OO  literature.  I  think  this  book  could  be  used  successfuliy  in  a 
second-level  comparative  languages  course. 


Booch,  Grady.  Software  Components  With  Ada  Structures,  Tools,  and  Subsystems. 


Benjamin-Cummings.  1987.  635p. 

Catalogs  reusable  software  components  and  provides  examples  of  Ada 
programming  style.  Presents  a  study  of  data  structures  and  algorithms  using  Ada. 


This  work  is  an  encyclopedic  presentation  of  data  structure  packages  from  Booch's  CX)D 
point  of  view.  It  is  great  for  those  who  love  taxonomies.  Ifs  not  for  the  faint-hearted, 
because  the  volume  of  material  can  be  overwhelming.  It  could  senre  as  a  text  for  an 
advanced  data  structures  course,  but  ifs  thin  in  "big  O"  analysis  and  other 
algorithm-theory  matters.  The  book  is  keyed  to  the  (purchasable)  Booch  Components. 

Bover,D.  Introduction  to  Ada.  Addison-Wesley,  1991. " 

Bover,  D.C.C.,  K.J.  Madunas,  and  M.J.  Oudshoom.  Ada:  A  First  Course  in  Programming 
and  Software  Engineering.  Addison-Wesley,  1992. 

This  work  is,  to  our  knowledge,  the  fimt  Ada  book  to  emerge  from  Australia,  from 
a  group  of  authors  with  much  collective  experience  in  teaching  Ada  to  first-year 
students.  A  number  of  interesting  examples  are  presented,  for  example,  an 
Othello  game.  The  book  is  full  of  gentle  humor,  a  definite  advantage  in  a  world 
of  dry  and  serious  texts.  In  the  book's  favor  is  the  large  number  of  complete 
programs.  On  the  other  hand,  it  is  rather  "European"  in  its  terseness;  American 
teachers  may  miss  the  pedagogical  apparatus  and  "hand-holding"  typically  found 
in  today's  CS1  books.  Generic  units  are  hardly  mentioned. 

Bryan,  O.L,  and  G.  Mendal.  Exploring  Ada.  Volume  1.  Prentice-Hall,  1990.  41  Ip. 

Describes  Ada's  type  model,  statements,  packages  and  subprograms.  Includes 
programming  features  such  as  information  hiding,  facilities  to  model  parallel  tasks, 
data  abstraction,  and  software  reuse.  * 

This  is  an  excellent  study  of  some  of  the  interesting  nooks  and  crannies  of  Ada; 
it  sometimes  gets  tricky  and  "ianguage-lawyeriy."  Volume  2  takes  up  tasking, 
generics,  exceptions,  derived  t^s,  scope  and  visibility;  Volume  1  covers 
everything  else.  The  programs  are  short  and  narrowly  focused  on  specific 
language  issues.  If  you  like  Bryan's  "Dear  Ada"  column  in  Ada  Letters,  you'll  like 
this  book.  It  is  certainly  not  a  book  for  beginners,  but  great  fun  for  those  who 
know  Ada  already  and  wish  to  explore. 

Burns,  A.  Concurrent  Programming  in  Ada.  (Ada  Ck}mpanion  Series)  Cambridge 
University  Press,  1985.  241  p. 

Reports  on  Ada  tasking  offering  a  detailed  description  and  an  assessment  of  the 
Ada  language  concerned  with  concurrent  programming.  * 

I  used  this  book  for  years  in  my  concurrency  course.  It's  roughly  equivalent  to 
Gehani's  book,  but  its  age  is  showing.  Cambridge  Press  is  not  always  easy  to  get 
books  from,  especially  in  the  US. 


Burns,  A.,  and  A.  Weliings.  Real-Time  Systems  and  Their  Programming  Languages. 
Addison-Wesley,  1990.  575p. 

Provides  a  study  of  real-time  systems  engineering,  and  describes  and  evaluates 
the  programming  languages  used  in  this  domain.  Considers  three  programming 
languages  in  detail:  Ada,  Modula-2  and  Occam2.  * 

Bums,  A.  A  Review  of  Ada  Tasking.  (Lecture  Notes  in  Computer  Sdenoe  Series,  Volume 
262)  Springer- Veriag,  1987.  * 

Caverly,  P.,  and  P.  Goldstein.  Introduction  to  Ada:  A  Top  Down  Approach  for 
Programmers.  Brooks-Cole,  1986.  237p. 

Organizes  and  emphasizes  those  features  that  distinguish  Ada  from  other 
programming  languages.  Uses  a  cyclical  approach  to  the  treatment  of  many 
topics.  Gives  a  brief  history  of  the  development  of  the  Ada  language.  Introduces 
the  I/O  capabilities,  procedures,  character  and  numeric  data  types  and  subtypes, 
and  the  concept  of  an  Ada  program  library.  Discusses  enumeration,  array,  record, 
and  derived  types  and  demonstrates  how  the  package  can  be  used  to  encapsulate 
data  types.  Explains  access  types  s^d  applications  and  the  encapsulation  of  data 
objects  in  packages.  Illustrates  how  finite-state  machines  can  be  represented  by 
packages.  Describes  the  essentials  of  tasking  and  deals  with  blocks  and 
exceptions.  Introduces  the  reader  to  private  types,  types  with  discriminates,  and 
generic  units.  * 

Chirlian,  Paul  M.  Introduction  to  Ada.  Weber  Systems,  1985.  291  p. 

Provides  a  basic  course  in  the  Ada  programming  language.  (Ada  courses  and/or 
self-study)  * 

Clark,  Robert  G.  Programming  in  Ada:  A  First  Course.  Cambridge  University  Press,  1985. 
21 5p. 

Introduces  the  Ada  programming  language.  Targets  persons  without  previous 
experience  in  programming.  Details  how  to  design  solutions  on  a  computer. 
Concentrates  on  solving  simple  problems  in  the  early  sections:  the  later  sections 
explore  how  packages  can  be  used  in  constructing  large  reliable  programs. 
Emphasizes  central  features  such  as  data  types,  subprograms,  packages, 
separate  compilation,  exceptions  and  files.  ANSI/MIL-STD-1815A-1983  is 
referenced  throughout  the  book.  * 

Cohen,  N.C.  Ada  as  a  Second  Language.  McGraw-Hill,  1986.  838p. 

Explains  Ada  to  those  who  wish  to  acquire  a  reading  and  writing  knowledge  of  the 
Ada  language.  Also  a  programming  reference  source.  * 

This  book  is  a  quite  comprehensive  exploration  of  Ada  which  follows  the  LRM  in 
its  presentation  order.  My  graduate  students  like  it  because  it  is  more  detailed  and 
complete  than  alternative  texts.  It’s  an  excellent  book  for  students  who  know  their 
languages  and  want  to  study  all  of  Ada.  There  are  good  discussions  of  "why's  and 
wherefore's"  and  many  long,  fully-worked  examples. 


Cooling,  J.E.,  Introduction  to  Ada.  Chapman  and  Hall,  1993.  576p. 

Introduction  to  Ada  gives  a  comprehensive  introduction  to  the  subject,  covering  all 
the  basic  aspects  of  the  language  with  reference  to  the  particular  strengths  of  Ada 
in  real-time  systems.  It  is  written  primarily  for  the  novice  programmer  who  lacks 
experience  of  modem  high-level  languages.  * 

Culwin.  Ada:  A  Developmental  Approach.  Prentice-Hall,  1992. 

Intended  for  use  on  courses  which  teach  Ada  as  the  first  programming  language. 
The  book  is  designed  to  take  the  reader  from  the  basic  principles  of  programming 
to  advanced  techniques.  This  books  provides  a  complete  introduction  to  software 
development  using  ^e  programming  language,  Ada.  It  is  not  only  concerned  with 
the  production  of  Ada  programs,  but  it  is  also  an  introduction  to  the  process  of 
implementation  and  testing.  Features  include:  a  carefully  structured  tutorial  which 
includes  software  developments,  design,  testing,  and  production.  * 

This  work  introduces  Ada  along  with  a  good  first-year  approach  to  software 
development  methodology.  Much  attention  is  paid  to  program  design, 
documentation,  and  testing.  Enough  material  is  present  in  data  structures  and 
algorithm  analysis  is  present  to  carry  a  CS2  course.  A  drawback  of  the  book  is 
that  the  first  third  is  quite  "Pascal-like"  in  its  presentation  order;  procedures, 
including  nested  ones,  are  presented  rattier  early,  and  packages  are  deferred  until 
nearly  the  middle  of  ttie  book.  This  is  certainly  not  a  fatal  flaw,  but  it  will  frustrate 
teachers  wishing  a  more  package-oriented  presentation.  The  programs  and 
solutions  are  apparently  available  from  the  author. 

Dawes,  J.  The  Professional  Programmers  Guide  to  Ada.  Pittman  Publishing,  1988.  * 

Delillo,  N.J.  A  First  Course  in  Computer  Science  with  Ada.  Richard  D.  Irwin,  Inc.,  1993. 

This  book  is  a  first  in  the  Ada  literature;  a  version  comes  with  an  Ada  compiler,  the 
AETech-IntegrAda  version  of  Janus  Ada.  Author,  publisher,  and  software  su^ier 
are  to  be  commended  for  their  courage  in  this.  The  book  itself  covers  all  the  usual 
CS1  topics,  in  my  opinion,  the  order  of  presentation  is  a  bit  too  Pascal-like,  with 
functions  and  procedures  introduced  in  Chapter  5  (of  15)  and  no  sign  of  packages 
(other  than  Text.lO)  until  Chapter  10.  Unconstrained  arrays  and  generics  are, 
however,  done  nicely  for  this  level,  and  Chapter  13  is  entirely  devoted  to  a  single 
nontrivial  case  study,  a  statistical  package.  I  wish  there  were  more  complete 
programs  in  the  early  chapters,  to  put  the  (othenmse  good)  discussion  of  control 
and  data  structures  in  better  context. 

Dorchak,  S.F.,  and  P.B.  Rice.  Writing  Readable  Ada:  A  Case  Study  Af^mach.  Heath, 

1989.  244p. 

Contains  a  style  guide,  which  gives  suggestions  for  enhancing  code  readability; 
devotes  a  chapter  to  the  discussion  of  concurrency,  and  advanced  feature  of 
modem  programming  languages;  a  fully  coded  Ada  program,  along  with  a  sample 
run;  a  bibliography,  which  lists  books  and  articles  about  Ada  and  software 


engineering  principles;  two  indexes,  one  devoted  exclusively  to  references  of  case 
study  modules  and  the  other  listing  Important  topics  and  concepts.  * 

Elbert,  T.F.  Embedded  Programming  in  Ada.  Van  Nostrand  Reinhold,  1989.  523p. 

Clarifies  Ada  for  the  practicing  programmer  and  for  the  advanced  engineering  or 
computer  science  student.  Assumes  the  reader  has  acquired  a  certain  level  of 
sophistication,  general  concepts  normally  found  in  introductory  programming  texts 
are  not  covered.  Also,  presumes  the  reader  is  familiar  with  operating  systems  and 
has  a  basic  knowledge  of  some  block-structured  languages  such  as  PL/I  and 
Pascal.  * 

Feldman,  M.B.  Data  Structures  with  Ada.  Prentice  Hall,  1985  (now  distributed  by 

Addison- Wesley).  (CS2/data  structures) 

This  book  is  a  reasonable  approximation  to  a  modem  CS2  book;  "big  O"  analysis, 
linked  lists,  queues  and  stacks,  graphs,  trees,  hash  methods,  and  sorting,  are  all 
covered.  The  Ada  is  a  bit  old-fashioned,  especially  the  lack  of  generics;  the  book 
was  published  before  compilers  could  handle  generics.  The  packages  and  other 
programs  are  available  free  from  the  author.  The  book  is  currently  under  revision 
with  Addison-Wesley  and  should  appear  in  1993. 

Feldman,  M.B.,  and  E.B.  Koffman.  Ada  Problem  Solving  &  Program  Design.  Addison- 

Wesley,  1991. 

Designed  to  introduce  the  novice  to  a  number  of  Ada  features,  such  as 
subprograms,  packages,  operator  overloading,  enumeration  types,  and  array¬ 
handling  operations.  Emphasizes  throughout  the  book  the  principles  of  data 
abstraction,  software  engineering,  problem  solving,  and  program  design.  * 

This  work  combines  the  successful  material  from  Koffman's  CS1  pedagogy  with 
a  software-engineering-oriented  ^a  presentation  order.  Packages  are  introduced 
early  and  emphasized  heavily;  chapters  on  abstract  data  types,  unconstrained 
arrays,  generics,  recursion,  and  dynamic  data  structures  appear  later.  The  last 
five  chapters,  combined  with  some  language-independent  algorithm  theory,  can 
serve  as  the  basis  of  a  CS2  course.  A  diskette  with  all  the  fully-worked  packages 
and  examples  (about  180)  is  included;  the  instructor's  manual  contains  a  diskette 
with  project  solutions. 

Feuer,  A.R.,  and  N.  Gehani.  Comparing  &  Assessing  Programming  Languages:  Ada,  C 

&  Pascal.  (Software  Series)  Prentice-Hall,  1984.  * 

Fischer,  C.,  and  R.  LeBlanc.  Crafting  a  Compiler.  Benjamin  Cummings,  1988.  (compilers) 
This  book  uses  Ada  as  its  language  of  discourse  and  Ada/CS,  a  usefully  large  Ada 
subset,  as  the  language  being  compiled.  If  you  can  get  the  "plain  Pascal"  tool 
software  by  ftp  from  the  authors,  you'll  have  a  good  translator-writing  toolset.  Skip 
the  Turbo  Pascal  diskette  version,  which  is  missing  too  many  pieces  to  be  useful. 
I've  used  the  book  since  it  came  out  with  both  undergrad  and  graduate  compiler 
courses;  it  embodies  a  good  blend  of  theory  and  "how  it's  really  done"  coding. 


Students  like  it.  The  authors  have  recently  published  a  second  version,  which 
uses  C  as  its  coding  language  but  retains  Ada/CS  as  the  language  being  compiled. 

Fisher,  D.A.,  editor.  Ada  Language  Reference  Manual.  Gensoft  Corp.,  1986.  * 

Gauthier,  M.  Ada:  Un  ^)prentissage.  (in  French).  Dunod,  1989. 

I  found  this  an  especially  interesting,  almost  philosophical  approach  to  Ada.  The 
first  section  presents  Ada  in  the  context  of  more  ^nerai  language  principles: 
types,  genericity,  reusability.  The  second  section  introduces  te^i^  arnl 
documentation  concerns,  as  well  as  tasking;  the  third  considers  generics  and 
variant  records  in  the  more  general  context  of  polymorphism.  For  mature  Ada 
students  in  the  French-speaking  world,  and  others  who  can  follow  technical 
French,  this  book  can  serve  as  a  different  slant  on  the  conventional  presentations 
of  the  language.  An  English  translation  would  be  a  real  contribution  to  the  Ada 
literature. 

Gehani,  N.  Ada:  Concurrent  Programming.  (2nd  edition).  Silicon  Press,  1991. 

This  is  a  less  formal,  more  Ada-oriented  presentation  of  concurrency  than  the 
Ben-Ari  work.  I  use  both  books  in  my  concurrency  course;  its  real  strength  is  the 
large  number  of  nontrivial,  fully  worked  examples.  Gehani  offers  a  nice  critique  of 
the  tasking  model  from  the  point  of  view  of  an  OS  person.  The  preface  promises 
the  availability  of  a  software  disk  from  the  publisher. 

Gehani,  N.  Ada:  An  Advanced  Introduction.  2nd  edition.  Prentice-Hall,  1989.  280p. 

Introduces  advanced  problem-solving  in  Ada.  Emphasizes  modular  programming 
as  good  programming  practice.  * 

I've  always  liked  Gehani's  literate  writing  style;  he  knows  his  languages  and  treats 
Ada  in  an  interesting,  mature,  and  balanced  fashion.  This  book  comes  with  a 
diskette  sealed  in  the  back  of  the  book,  which  is  advantageous  because  the  book 
has  numerous  nontrivial,  fully-worked  examples. 

Gehani,  N.  Unix  Ada  Programming.  Prentice-Hall,  1987. 31  Op. 

Focuses  on  the  novel  aspects  of  the  Ada  language  and  explains  them  by  many 
examples  written  out  in  fuli.  Examines  the  interesting  differences  between  ^e  Ada 
language  and  other  programming  languages.  Also,  notes  the  similarities  between 
Ada,  Pascal,  C,  PL/I,  and  Fortran.  * 

Gonzalez,  D.  Ada  Programmer's  Handt>ook.  Benjamin-Cummings,  1991.  * 

Gonzalez,  Dean  W.  Ada  Programmer’s  Handbook  and  Language  Reference  Manual. 

Benjamin-Cummings,  1991.  200p.  * 

Habermann,  A.,  and  Dwayne  E.  Perry.  Ada  for  Experienced  Programmers.  (Computer 

Science  Series)  Addison- Wesley,  1983. 480p. 

Offers  a  comparative  review  of  Ada  a^  Pascal,  using  dual  program  examples  to 


illustrate  software  engineering  techniques.  * 

Hibbard.  Peter,  et  al.  Studies  in  Ada  Style.  2nd  edKion.  Springer-Verlag.  1983.  lOlp. 
Presents  concepts  of  the  abstractions  embodied  in  Ada  with  five  examples;  a 
queue,  a  graph  structure,  a  console  driver,  a  table  handler  and  a  solution  to 
Laplace's  equation  using  multiple  tasks.  * 

Jones,  Do-While.  Ada  in  Action  with  Practical  Programming  Examples.  John  Wiley  & 
Sons,  1989. 

Helps  Ada  programmers  avoid  common  pitfalls  and  provides  them  with  many 
reusable  Ada  routines.  Discusses  a  variety  of  numeric  considerations,  user 
interfaces,  utility  routines,  and  software  engineering  arid  testing.  Provides 
examples  of  Ada  code.  * 

Katzan,  H.,  Jr.  Invitation  to  Ada  &  the  Ada  Reference  Manual.  Petrocelli,  1982.  429p. 
Calls  for  the  scientific  computing  community  to  adopt  the  Ada  programming 
language.  Part  II  is  the  Ada  Reference  Manual,  1980  version.  * 

Krieg-Brueckner,  B.,  et  al,  editors.  Anna  :  A  Language  for  Annotating  Ada  Programs. 
(Lecture  Notes  in  Computer  Science  Series.  Volume  260)  Springer-Verlag,  1987.  ‘ 

Ledgard,  Henry.  Ada:  A  First  Introduction.  2nd  edition.  Springer-Verlag,  1983. 130p. 
Assumes  that  the  reader  has  experience  with  some  other  higher  order 
programming  language.  Outlines  several  key  features  of  Ada;  a  treatment  of  the 
facilities-concept  of  data  types,  the  basic  statements  in  the  language, 
subprograms,  packages,  and  general  program  structure.  * 


Lomuto,  N.  Problem-Solving  Methods  with  Examples  in  Ada.  Prentice-Hail, 
1987.(algorithms) 

Inspired  by  Polya's  classic  How  to  Solve  It,  this  book  can  make  a  nice  addition  to 
an  Ada-orient^  algorithms  course,  it  makes  too  many  assumptions  about 
students'  programming  background  to  use  as  a  CS1  book,  and  doesn't  teach 
enough  Ada  to  be  an  "Ada  book."  But  it  makes  nice  reading  for  students 
sophisticated  enough  to  handle  it.  I'd  classify  it  as  simiiar  to  Bentley's 
Programming  Pearls. 

Luckham,  David  C.,  et  al.  Programming  with  Specifications:  An  Introduction  to  Anna,  a 
Language  for  Specifying  Ada  Programs.  (Texts  and  Monographs  in  Computer  Science) 
Springer-Verlag,  1990.  41 6p. 

Offers  an  in-depth  look  at  ANNA,  a  form  of  the  Ada  language  in  which  specially 
marked  comments  act  as  formal  annotations  about  the  program  to  which  they  are 
attached.  * 


Lyons,  T.G.  Selecting  an  Ada  Environment.  (Ada  Companion  Series)  Cambridge 
University  Press.  1986.  239p. 


Provides  an  overview  of  the  Ada  Programming  Support  Environment  (APSE). 
Covers  six  main  issues  in  selecting  an  environment.  Contains  summaries  of 
current  approaches  to  likely  problems,  indications  of  deficiencies  in  existing 
knowledge,  and  checklists  of  questions  to  ask  when  considering  a  particular 
environment.  * 

Mayoh,  B.  Problem  SoMrtg  with  Ada.  (Wiley  Series  in  Computing.)  Reproduction  of  1982 
edition  * 

Mendal.  G..  and  D.L  Bryan,  Exploring  Ada.  Volume  2.  Prentice-Hall.  1992. 

A  method  of  presentation  based  on  the  Socratic  method,  provides  coverage  and 
the  semantics  of  Ada.  Discusses  focused  problems  individually.  The  second 
volume  expands  on  the  larger  issues  dealing  with  Ada's  more  advanced  features.* 

Miller.  N.E.  and  C.G.  Petersen.  File  Structures  with  Ada.  Benjamin/Cummings,  1990.  (file 
structures) 

Designed  for  a  .straightforward  ACM-curriculum  file  structures  course,  this  book 
succeeds  at  what  it  does.  There  are  good  discussions  of  ISAM  and  B-tree 
organizations.  The  software  can  be  purchased  a  low  cost  from  the  authors;  it 
seems  to  approximate  in  Ada  all  those  C-based  file  packages  advertised  in 
programmer-oriented  trade  publications. 

Nyberg,  K.A.,  editor.  Annotated  Ada  Reference  Manual.  2nd  edition.  Grebyn  Corp.,  1991. 
Contains  the  full  text  of  ANSI/MIL-STD-1815A  with  Inline  annotations  derived  from 
the  Ada  Rapporteur  Group  of  the  international  Organization  for  Standards 
responsible  for  maintaining  the  Ada  language.  * 

This  is  the  definitive  work  on  Ada  legalities,  because  it  presents  not  only  the  full 
text  of  the  LRM  but  also  the  official  Ada  Interpretations  as  prepared  by  the  Ada 
Rapporteur  Group  of  Working  Group  9  of  the  International  Organization  for 
Standardization  (ISO)  and  approved  by  that  organization.  These  commentaries, 
interleaved  with  the  LRM  text,  are  promulgated  by  the  Ada  Joint  Program  Office, 
the  American  National  Standards  Institute  (ANSI)  agent  for  Ada,  in  the  Ada 
Compiler  Validation  Suite  (AC VC).  They  are  thus  binding  upon  compiler 
developers.  I  recommend  this  book  as  an  essential  volume  in  the  iibrary  of  every 
serious  Ada  enthusiast. 

Pokrass,  D.,  and  G.  Bray.  Understanding  Ada:  A  Software  Engineering  Approach.  John 
Wiley  and  ^ns,  1985.  * 

Saib,  S.,  and  R.E.  Fritz.  Introduction  to  Programming  in  Ada.  HR&W,  1985  * 

Saib,  Sabina  H..  and  R.E.  Fritz.  Tutorial:  The  Ada  Programming  Language.  IEEE 
Computer  Society,  1983.  538p. 

Covers  such  topics  as  the  history  and  current  status  of  Ada;  basic  language; 
schedule  for  industry  and  DoD;  preventing  error;  readable,  maintainable,  modular 


systems;  real-time  features,  portability;  and  environments  for  Ada.  * 

Savrtch,  W.J.,  ot  al.  Ada:  An  Introduction  to  the  Art  and  Science  of  Programming. 

Benjamin-Cummings,  1992. 

Written  specifically  for  the  first  programming  course.  It  starts  with  variable 
declarations,  simple  arithmetic  expressions,  simplified  input-output,  and  builds 
upward  toward  subprograms  and  packages.  A  chapter-by-chapter  instructor's 
guide  is  also  available,  as  is  a  program  disk  with  more  that  140  completed 
programs  from  the  text.  * 

This  is  a  straightforward  adaptation  of  ^e  well-known  Savitch  Pascal  books.  Ada 
is  introduced  in  a  Pascal-like  order,  with  subtypes  and  packages  introduced 
halfway  through  the  book.  This  is  purely  a  CS1  book.  The  final  chapter  covers 
dynamic  data  structures.  There  is  minimal  covers^  of  unconstrained  array  t^s; 
generics  are  introduced  at  th  haifv  point  to  explain  TextJO,  then  continued 
only  in  the  final  chapter.  Th  uthors  intended  this  book  to  provide  a  painless 
transition  to  Ada  for  teachers  ot  Pascal;  one  wishes  they  had  taken  advantage  of 
the  chance  to  show  some  of  the  interesting  Ada  concepts  as  well.  Program 
examples  from  the  text  are  available  on  disk,  but  only  as  part  of  the  instructor’s 
manual;  a  solutions  disk  is  available  for  a  fee  from  the  authors. 

Schneider,  G.M.,  and  S.C.  Bruell.  Concepts  in  Data  Structures  and  Software 

Development  (with  Ada  Supplement  by  P.  Texel).  West.  1991.  (CS2/data  structures) 
This  work  is  not,  strictly  speaking,  an  Ada  book;  rather,  it  is  a  solid, 
language-independent  approach  to  modem  CS2.  The  language  of  discourse  in  the 
book  is  a  Pascal-like  AOT  language  rather  like  Modula-2  in  style;  some  examples 
are  coded  in  legal  Pascal.  The  Ada  supplement  makes  it  usable  in  an  Ada-based 
course,  but  the  supplement  is  rather  too  terse  (100  pages  of  large  type)  for  my 
taste,  and  insufficiently  well  keyed  to  the  book  chapters.  The  supplement's 
effectiveness  would  be  greatly  enhanced  by  full  translations  to  Ada  of  a  large 
number  of  the  book's  examples. 

Sebesta,  R.W.  Concepts  of  Programming  Languages.  (2nd  ed.).  Benjamin  Cummings, 

1993.  (comparative  languages) 

If  you've  been  around  for  a  while,  you  might  remember  the  late  Mark  Elson's  1975 
b(rok  by  the  same  title.  This  is  similar;  a  concept-by-concept  presentation,  with  - 
in  each  chapter  -  examples  taken  from  several  languages.  I  include  this  work  in 
an  "Ada  lisr  because  I  like  its  nice,  impartial  coverage  of  Ada.  I  especially  like  the 
chapters  on  abstraction  and  exception  handling.  The  book  covers  - 
comparatively,  of  course  -  most  of  the  languages  you'd  like  to  see,  including  C, 
Lisp,  Smalltalk,  etc.,  with  nice  historical  chapters  as  well.  The  book  is 
readable;  my  students  like  it.  Our  undergraduate  and  graduate  courses  both  use 
it  as  a  base  text. 

Shumate,  K.  Understanding  Ada.  2nd  edition,  John  Wiley  &  Sons. " 


This  would  make  a  CS1  book  if  it  included  more  overall  pedagogy,  independent 
of  language  constructs.  Otherwise  it  Is  a  nice  introduction  to  Ada  in  fairly  gentle 
steps.  Lots  of  completely  worked  examples,  right  from  the  start.  Doesn't  follow 
the  LRM  order,  which  is  great. 

Shumate,  K.C.  Understanding  Ada:  \Mth  Abstract  Data  Types.  2nd  edition.  John  Wiley 
&  Sons,  1989.  * 

Skansholm,  J.  Ada  from  the  Beginning.  Addison-Wesley,  1986.  61 7p. 

Describes  the  principles  and  concepts  of  programming  in  a  logical  and  easy-to- 
understand  sequence  and  discusses  ttie  important  features  of  Ada  (except  parallel 
programming).  Teaches  the  basic  of  writing  computer  programs.  Emphasizes  the 
fundamentals  of  good  programming.  Provides  a  grounding  in  the  programming 
language  Ada.  Covers  the  following:  programming  designs,  the  basics  of  Ada, 
control  statements,  types,  subprograms,  data  structures,  packages,  input/ouput, 
exceptions,  dynamic  data  structures,  files,  and  generic  units.  * 

This  book  was  one  of  the  first  to  use  Ada  with  CS1 -style  pedagogy.  There  are 
excellent  sections  on  the  idiosyncracies  of  interactive  I/O  (a  problem  in  all 
languages),  and  a  sufficient  number  of  fully-worked  examples  to  satisfy  students. 
Generics,  linked  lists  and  recursion  are  covered  at  the  end;  there  is  no  tasking 
coverage,  but  one  would  not  expect  this  at  CS1 -level. 

Smith.  Introduction  to  Programming  Concepts  and  Methods  vnth  Ada.  McGraw-Hill,  1993. 

* 

Stratford-Collins,  M.J.  Ada:  A  Programmer's  Conversion  Course.  (Ellis  Norwood  Series 
in  Computers  &  Their  Applications)  John  Wiley  &  Sons,  1982.  * 

Tremblay.  J.,  et  al.  Programming  in  Ada.  McGraw-Hill,  1990.  PG  486p. 

Explains  computer  science  concepts  in  an  algorithmic  framework,  with  a  strong 
emphasis  on  problem  solving  and  solution  development.  * 

Volper,  D..  and  M.D.  Katz.  Introduction  to  Programming  Using  Ada.  Prentice-Hall,  1990. 
650p. 

Uses  the  spiral  approach  as  the  presentation  methodology  in  this  introductory 
course  in  Ada  programming.  * 

This  book  uses  a  heavily  "spiraled”  approach  to  Ada.  and  is  designed  for  a 
2-semester  course,  covering  nearly  all  of  Ada  eventually.  There  are  lots  of 
fully-coded  examples,  and  good  pedagogical  sections  on  testing,  coding  style,  etc. 
If  you  like  spiraling,  you'll  like  this.  The  down  side  is  that  you  cani  find  all  you 
need  on  a  given  subfsct  in  one  place.  It's  at  the  other  end  of  the  scale  from  the 
"Ada  books"  that  follow  the  Ada  Language  Reference  Manual  (LRM)  order. 

Wallace,  Robert  H.  Practitioner's  Guide  to  Ada.  McGraw-Hill.  1986  373p. 


Discusses  the  issues  to  be  considered  when  making  the  transition  to  Ada,  on 
selecting  toolsets,  and  on  using  the  language  effectively.  Covers  the  following; 
Ada  as  a  language;  Ada  Oriented  Development  Environments;  Ada  oriented  design 
methodologies;  Ada  policies  and  standards;  Ada  products  and  vendors;  sources 
of  Ada-related  information;  making  ^e  transition  to  Ada  and  other  uses  of  Ada.  * 

Watt,  D.A.,  B.A.  Wichmann,  et  al.  Ada  Language  and  Methodology.  Prentice-Hall,  1987. 
This  work  presents  some  interesting  programming  projects,  and  the  coverage  of 
design  and  testing-at  the  level  of  a  first-year  student-is  quite  good.  The  first  third 
of  the  book  concentrates  heavily  on  classical  control  and  data  structures,  leaving 
exceptions,  packages  and  even  procedures  until  the  "programming  in  the  large" 
material  in  the  second  third.  CS2  teachers  will  find  too  little  concentration  on 
algorithm  analysis.  On  the  other  hand,  tasking  and  machine-dependent 
programming  are  covered.  Like  the  Shumate  work,  this  book  would  make  a 
suitable  introduction  to  Ada  for  students  with  a  semester  or  so  of  programming 
experience;  it  "jumps  in"  too  quickly  to  satisfy  the  needs  of  neophytes  and  is  not 
well-tailored  to  CS1  or  CS2  needs. 

Weiss,  M.A.  Data  Stnjctures  and  Algorithms  in  Ada.  Benjamin/Cummings,  1993. 

I'm  taking  a  gamble  here  in  reviewing  a  book  I  haven't  seen,  but  I  have  perused 
the  C  version  of  this  book  and  think  it  reaches  its  intended  market  -  data 
structures  courses  (CS7)  -  r^iher  well.  There's  a  good  mixture  of  theory  and 
practice  (ADT  design,  for  example),  and  coverage  of  new  topics  like  amortized 
algorithm  analysis  and  splay  trees.  A  book  at  this  level  should  not  pay  too  much 
attention  to  teaching  a  language;  rather  it  should  make  good  use  of  its  language 
of  discourse.  The  Ada  version  has  not  appeared  yet  at  this  writing;  if  it  uses  Ada 
as  well  as  the  C  version  uses  C,  the  book  is  a  winner  at  its  level,  and  sorely 
needed  in  the  Ada  literature. 


c.  CASE  Tools 


There  is  a  wide  range  of  CASE  tools  available.  The  low  end  CASE  tools  are  primarily 
drawing  tools  for  a  particular  development  notation.  As  the  utility  of  the  tools  increase, 
they  add  functions  such  as  data  dictionaries,  code  generators  and  traceability. 

Students  like  the  tools  which  are  code  generators,  but  they  are  disappointed  when  they 
find  out  that  most  of  them  only  generate  the  specificaton  and  not  the  bodies  of  p8K:kages. 

In  our  class  we  used  3  tools:  EasyCASE  for  structured  development,  OMTool  for 
Rumbaugh's  approach,  and  ObjectMaker  to  generate  Ada. 

The  list  of  tools  below  gives  the  source  of  the  tool,  its  functionality,  its  cost  in  1994,  ar 
the  hardware/software  environemt  it  in  which  it  operates. 

AD/Method 

Structured  Solutions 
functions  - 

data  and  process  modeling 
business  object/event  modeling 
technology  modeling 
project  templates 
enhancement  &  maintenance 

OpenSELECT 

Meridian  Software  Systems,  Inc. 

Irvine,  Calif, 
functions 

Yourdon/Demarco  methodologies 
Ward  Mellor  and  Hatley  extensions 
Jackson  structured  program  charts 
Chen  ERD's 
Constantine 
State  Transition 
DOS/Windows 
$795 

EasyCASE  Plus 

Evergreen  CASE  Tools 

8522  150  4th  Avenue  NE 
Redmond  Wash  98052 
functions 

methodologies 

Gane  &  Sarson 
Yourdon/DeMarco 


Ward‘Mellor/Hariey 

SSADM 

Yourdon/Conatantine 
Marting 
Chen 
Bachman 
IDEF1X 
diagram  types 
dataflow 
stat  transition 
structure 

entity  relationshop 
data  model 
entity  life  history 
logical  data  structure 
$495/$649/$795 

MacAnalyst  and  MacDesigner 
Excel  Software 
functions 

structured  analysis  &  design 
real-time  extensions 
data  modeling  &  screen  prototyping 
object-oriented  analysis  &  design 
data  dictionary  &  requirement  database 
Macintosh 

SiLVERRUN 

Computer  Systems  Advisers,  Inc. 

50  Tice  Blvd. 

Woodcliff  Lake.  NJ  07675 
functions 

reverse  data  engineering  to  ER  models 
graphical  relation  models  from  ER  models 
foreign  keys,  indexes  and  SQL  schemas 
Windows  /  OS/2  /  Macintosh 

McCabe  Tools 

McCabe  Associates 
functions 

generates  unit  and  integration  tests 
verify  executed  test  path  on  the  flow  graph 
reverse  engineering  by  abstracting  system  design 
UNIX  /  VMS  /  DOS 
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Foresight 

Computer  &  Engineering  Consultants 
$12500 

PC-METRIC 

SET  Laboratories 
PO  Box  868 
Mulino.  OR  97042 
Academic  version  $25.00 

Teamwork 

Cadre  Technologies  Inc. 

222  Richmond  Street 
Providence,  Rl  02903 

Sparcstations,  HP  300/400  workstations,  IBM  AIX, 
Ultrix,  Apollo  Domain,  HP  700.  and  VMS 

Paradigm  Plus 

Protosoft,  Inc. 
functions 

open  architecture 
diagram  editor 
matrix  editor 
script  language 
automatic  diagram  generation 
automatic  digram  leveling 
Rumbaugh's  OMT 
Booch/Buhr  OOD 
HOOD  method 
EVB  method 

Yourdon/OeMarco/Gane/Sarson  SASD 
Chen/Bachman  Entity  relation 
Customizable  report/code  generation 
Code  generation  for  C-i'+,  C,  Ada,  and  others 
DOS/Windows,  UNIX/Motif,  OS/2,  Sun,  HP,  RS6000 

Corvision 

Cortex  Corporation 


Daisys 

S/Cubed,  Inc. 

Design/IDF  &  CPN 

Meta  Software  Corp. 
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EasyCase  Professional 

Evergreen  CASE  Tools 
8522  150th  4th  Ave  NE 
Redmond  Washington.  98052 


ObjecTool 

Object  International 
8140  N.  MoPac  4-200 
Austin.  TX  78759 

OOA-OOD 

Windows 

ObjectMaker 

Mark  V  Systems 
Encino  CA 
functions 

C  code  generator 
Ada  code  generator 
structured  methods 
20  00  methods 
Windows  /  WindowsNT 

OMTTool 

General  Electric  Advanced  Concepts  Center 
640  Freedom  Business  Center 
POBox  1561 

King  of  Prussia,  PA  19406 


POSE 

Computer  Systems  Advisers,  Inc. 
50  Tice  Boulevard 
Wooddiff  Uke,  NJ  07675 
functions 
DFD 

drawings  of  the  diagrams 
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